Subject: [Enum] SIP 6th bake-off and enum

From: Kevin McCandless <[email-masked]>
Date: Mon, 22 Jan 2001 07:00:45 -0800

Did anyone attend the 6th SIP bake-off?  I saw a report from pulver.com that
mentioned seventeen SIP vendors demostrated early stages of ENUM
integrationduring.  Any comments??

Seventeen SIP vendors demonstrated early stages of ENUM integration
activity at the 6th SIP Bake-off by translating telephone numbers to SIP
URI's in the call set-up process through utilizing ENUM services from
NetNumber.com.   ENUM is the name for the IETF standard (RFC 2916) that
defines a DNS-based mechanism for mapping a telephone number to a list of
Internet addresses or resources associated with that number.  

Kevin McCandless
Senior Network Planner
Illuminet
913-814-6397
[email-masked]

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

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Jan 2001 11:05:06 -0500

>integrationduring.  Any comments??

Well this is a "good thing" .. but I'm assuming this was the use of ENUM 
_technology_  with private dialing plans.

>Internet addresses or resources associated with that number.

I hate to be a stickler for detail here but Pulver is a bit off . RFC 2916 
is quite clear about this ..ENUM is about the integration of the ITU-T 
E.164 plan into e164.arpa and the status of that delegation is under active 
discussion among the Member States of the ITU.

No decisions have currently been made on the delegation of the country code 
zones to the appropriate Member States.

Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "A.M. Rutkowski" <[email-masked]>
Date: Mon, 22 Jan 2001 11:53:02 -0500

Hi Richard,

>E.164 plan into e164.arpa and the status of that delegation is under 
>active discussion among the Member States of the ITU.
>
>No decisions have currently been made on the delegation of the country 
>code zones to the appropriate Member States.

As was discussed at the ITU meeting, there are those
who disagree with your interpretation ENUM.

ENUM is no less ENUM if the protocols are instantiated
in a zone other than E164.ARPA.  Indeed, in some jurisdictions,
it's entirely possible it may never be instantiated in
that zone.  Indeed, it seems important for IETF to stick to
protocol development rather than pre-ordaining competitive
opportunities in the marketplace.

--amr

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Jan 2001 13:33:50 -0500

At 11:53 AM 1/22/2001 -0500, A.M. Rutkowski wrote:
>Hi Richard,
>
>>I hate to be a stickler for detail here but Pulver is a bit off . RFC 
>>2916 is quite clear about this ..ENUM is about the integration of the 
>>ITU-T E.164 plan into e164.arpa and the status of that delegation is 
>>under active discussion among the Member States of the ITU.
>>

You disagreed with the interpretation if I recall....

>in a zone other than E164.ARPA.

Wrong... READ RFC 2916

>  Indeed, in some jurisdictions,
>that zone.

Unless you know of some DNS resolver technology that I'm unaware of, if we 
are to map the totality of ITU_T Recommendation E.164 into the DNS it will 
have to be in a single DNS tree, properly delegated along Member State 
lines according the recommendations of the plan itself . Classic DNS 
resolvers cannot recursively search multiple domains to find an authoritive 
NS. This, of course does not preclude the use of private domains for 
private dialing plans.

>   Indeed, it seems important for IETF to stick to

With all due respect you are totally incorrect.

What is clear is that you do not accept the results of the open consensus 
based IETF process, the result of the ENUM WG and somehow wish to rewrite 
or somehow abdicate RFC2916.

You are well aware of what RFC 2916 states and states clearly at the 
beginning of the RFC and at the end when the IANA instructions are made. 
ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa.

If you wish to revisit the decision of the IESG in this matter ....your 
appeals should be directed at the IAB.

###########################

2. E.164 numbers and DNS

    The domain "e164.arpa" is being populated in order to provide the
    infrastructure in DNS for storage of E.164 numbers.  In order to
    facilitate distributed operations, this domain is divided into
    subdomains.  Holders of E.164 numbers which want to be listed in DNS
    should contact the appropriate zone administrator in order to be
    listed, by examining the SOA resource record associated with the
    zone, just like in normal DNS operations.

    Of course, as with other domains, policies for such listings will be
    controlled on a subdomain basis and may differ in different parts of
    the world.

    To find the DNS names for a specific E.164 number, the following
    procedure is to be followed:

   1.  See that the E.164 number is written in its full form, including
       the countrycode IDDD.  Example: +46-8-9761234

   2.  Remove all non-digit characters with the exception of the leading
       '+'.  Example: +4689761234

   3.  Remove all characters with the exception of the digits.  Example:
       4689761234

   4.  Put dots (".") between each digit.  Example: 4.6.8.9.7.6.1.2.3.4

   5.  Reverse the order of the digits.  Example: 4.3.2.1.6.7.9.8.6.4

   6.  Append the string ".e164.arpa" to the end.  Example:
       4.3.2.1.6.7.9.8.6.4.e164.arpa

##################################

4. IANA Considerations

    This memo requests that the IANA delegate the E164.ARPA domain
    following instructions to be provided by the IAB.  Names within this
    zone are to be delegated to parties according to the ITU
    recommendation E.164.  The names allocated should be hierarchic in
    accordance with ITU Recommendation E.164, and the codes should
    assigned in accordance with that Recommendation.

    Delegations in the zone e164.arpa (not delegations in delegated
    domains of e164.arpa) should be done after Expert Review, and the
    IESG will appoint a designated expert.
##########

---

From: "Douglas Ranalli" <[email-masked]>
Date: Mon, 22 Jan 2001 15:02:19 -0500

Richard et al,

IMHO, Tony is simply pointing out that there are discussions underway within
the ITU and various ITU Member States (including the US) regarding ENUM.  By
the vary nature of these discussions, multiple approaches are being
presented and reviewed.  As a participant in the discussions I think it is
fair to say that no conclusions have been reached at the ITU or Member State
level.  The ITU Study Group 2 hasn't concluded its review.  Furthermore, the
US Department of State just created a new ENUM Ad Hoc working group to study
this exact issue starting in mid-February so clearly no conclusions have
been reached.  Regardless of the outcome of the discussions, the "open
consensus building process" is alive and well.  Let's let the process work.

Doug

----- Original Message -----
From: Richard Shockey <[email-masked]>
To: A.M. Rutkowski <[email-masked]>; Richard Shockey
<[email-masked]>; Kevin McCandless <[email-masked]>;
<[email-masked]>
Sent: Monday, January 22, 2001 1:33 PM
Subject: Re: [Enum] SIP 6th bake-off and enum

---

From: "A.M. Rutkowski" <[email-masked]>
Date: Mon, 22 Jan 2001 15:23:38 -0500

Hi Richard,

>ENUM is about mapping ITU-T Recommendation E.164 into e164.arpa.

ENUM is about the following:

   1.
   Through transformation of E.164 numbers
   into DNS names and the use of existing DNS
   services like delegation through NS records,
   and use of NAPTR [1] records in DNS [2] [3],
   one can look up what services are available
   for a specific domain name in a decentralized
   way with distributed management of the
   different levels in the lookup process.

The reality is that it will have multiple instantiations.
Ultimately, as was agreed at the ITU, these will be national
matters...and shaped by the marketplace.  As such, we should
not further burden this list.

cheers,
tony

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Jan 2001 16:16:21 -0500

At 03:02 PM 1/22/2001 -0500, Douglas Ranalli wrote:
>presented and reviewed.

Oh I'm well aware of that ..but that does not alter the fact that RFC 2916 
is about mapping Recommendation E.164 into e164.apra.... its what the 
document says.

I completely agree there are multiple approaches on how achieve such a mapping.

>  As a participant in the discussions I think it is
>level.

Correct.

>   The ITU Study Group 2 hasn't concluded its review.

Correct

>  Furthermore, the

I'm in violent agreement ... Its just making sure we are discussing the 
same thing.... this is a discussion on RFC 2916 I presume.

So if there is a fundamental problem with RFC 2916 and its mapping of 
Recommendation E.164 into e164.arpa then it should be made very clear, what 
those problems are.

What I'm having some problems with is the cryptic remarks by some that RFC 
2916 is somehow anti-competitive, against private enterprise, an intrusion 
of government into the  Internet etc without spelling out what those 
objections are and whose economic interest is being harmed here and why 
those economic interests are being harmed.

I'd certainly like to defend RFC 2916 in that IMHO it enables competition 
in telecom markets, creates new business models and opportunities, enables 
new services, reduces costs for carriers and enterprises , ends world 
hunger etc.  As for the E.164 plan, it has always been overseen by the 
Member States in order to insure its global consistency.  I do not need to 
go into the serious consumer protection and equal access issues that are on 
the table here.

I wish I could rewrite the DNS to allow for alternative resolution 
models..but if some one could describe how this could be done I'd be 
delighted to listen..

---

From: "A.M. Rutkowski" <[email-masked]>
Date: Mon, 22 Jan 2001 16:30:58 -0500

Hi all,

>consistency.  I do not need to go into the serious consumer protection and 
>equal access issues that are on the table here.

There is a diverse audience waiting with bated breath
at the forum for all these implementation issues at:

  [email-masked]

This will allow for fuller discussions on 12-13 Feb.

--tony