Subject: RE: [Enum] sipping-e164 comments

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 Feb 2002 03:29:15 -0600

Thanks for your notes, Richard. A few comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Stastny, Richard [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 8:32 AM
> To: 'Lawrence Conroy'; Jon
> Cc: [email-masked]
> Subject: RE: [Enum] sipping-e164 comments
> 
> 
> Hi,
> 
> first I would like to congratulate the authors for this execellent paper
on
> sip AND enum, and here I agree fully with Lawrence, that we need such a
> paper.
> 
> And of course, its too much concentrated on telephony and SIP issues, as
the
> title suggests.

I hope we cannot be faulted for that; as a choice of scope it intended no
offense to alternatives. Also note that it is a WG item of the SIPPING WG,
not ENUM, though we believe its scope requires review in both working
groups.

[snip]
> 
> I also see SG16 jumping up and down, but that may be resolved easily:
> First, many statements regarding SIP are also valid for h323,
> Second, its up to SG16 to write a similar paper, or even better, to
upgrade
> this paper to a generic paper dealing with both (this would be a nice job
> for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever)

Actually, I feel that H.323 and SIP are different in a number of well-known
respects, not the least of which is that I understand the commonly-deployed
versions of H.323 do not use URIs. I think we probably do need a
SIP-specific draft given some of the differences between the two.

Certainly, we invite any experts in H.323 to undertake a similar endeavor -
I'd be happy to provide any support I could to that purpose. I don't think
my own expertise anyway would be sufficient to take that on.

[snip]
> 
> Also nobody prevents my company to implement within our  network an
IN-like
> ENUM-like service, which is totally separate from the public ENUM (called
> operator ENUM), eventually running in an extranet with other operators.

To the extent that our document speaks to this issue, we understand that
what is called "ENUM" is that which is delegated beneath the e164.arpa
domain, and that everything else is not called "ENUM". I think this follows
RFC2916 as it is written today (maybe it will change in bis). I am aware of
the sorts of discussions you are referring to above (about "public ENUM" and
so forth), but we're just trying to stick to exactly what we read in the
IETF standard. As you surmise there is no technological impedement to
reusing the underlying technology (NAPTR) for non-E.164 numbers - it is just
a choice of scope as well. But note that this choice of scope entails unique
policy benefits that we find desirable.

[snip]
> There is no way currently to make sure that the telephone number is a
> complete E.164 number, especially on a global scale with a lot of
countries
> having open numbering plans and no fixed number length. Also networks may
> have no way of determining whether an address is complete. 

I am familiar with this problem; it is the general problem of converting
overlap to en bloc signaling in the GSTN. My point is just that ENUM is an
en bloc system, not an overlap system; there is nothing comparable to an
ISUP ACM (indicating that the address is known to be complete) or a SAM
(indicating that more digits have been supplied towards completion) or a SIP
484 (indicating that the address is known to be incomplete). In the absence
of these sorts of mechanisms ENUM is left in a bit of a lurch. However, I am
aware of GSTN-mechanisms (based on timers) that are used to resolve overlap
signaling into en bloc today that make it more tractable to solve this
problem before ENUM is invoked.

An alternative would be for ENUM to devise a system that differentiated
between a failure because a number didn't exist in the system and a failure
because an insufficient number of digits were supplied. I'm not aware of any
movement in that direction, though.

[snip]
> best regards
> Richard STASTNY
> OeFEG
> Arsenal Objekt 24
> P.O. Box 147
> A-1103 Vienna, Austria
> Tel: +43 664 420 4100
> Fax: +43 1 79780 13
> [email-masked]
> [email-masked]

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

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 15 Feb 2002 11:56:50 -0500

Hi Jon,

>policy benefits that we find desirable.

It is worth noting, however, that the U.S. Government has
explicitly decided this matter differently.  For other
significant policy benefits, it encourages multiple ENUM and
ENUM-like implementations.  The relevant document is available
at: http://www.ngi.org/enum/geneva200109/46_ww9.doc

Another policy "benefit" of the IAB decision:
Although impeded by RFC2804, a formally designated ENUM
implementation must necessarily comply with Lawful Interception
requirements under Council of the European Union Resolution of
17 January 1995, and the U.S. Communications Assistance for Law
Enforcement Act of 1994, as amended by the Patriot Act of
November 2001.  This is within the ambit of technical standards
work of the ETSI Standards Development Organization SEC LI
Working Group.  See TR 101 944, "Telecommunications Security;
Lawful Interception (LI); Issues on IP Interception."

--tony

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Feb 2002 09:27:44 -0800

Hi Tony,

At 11:56 AM 2/15/2002 -0500, Tony Rutkowski wrote:
>explicitly decided this matter differently.

1.  It is worth noting that you keep raising political issues in a 
technical forum.  The IETF does not work on the basis of governments.  It 
works on the basis of engineering.

2.  It is worth noting that your characterization of the submission to the 
ITU is just plain wrong.  Yes, it uses the word ENUM more generally than 
e164.arpa, but a) it notes the need for a single, coordinated operation, 
and b) use of the term ENUM was not offered as a decision.

3. By the way, the term ENUM is defined by the IETF in its document.  How 
others choose to use that term is their business, not the IETF's.

Given the pattern of your postings to this mailing list, it remains a 
mystery what purpose you are trying to serve.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464