Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion

From: "Jay R. Hilton" <[email-masked]>
Date: Thu, 12 Oct 2000 17:28:53 -0400

Richard and the ENUM list,

Sorry that I have been absent from the follow-up discussions from my original
query, but I am back now.

Thanks for the pointer to the ITU website for ENUM activities (
http://www.itu.infocom/enum).  I find the information contained on that site to
provide a good overview of the activities underway.  I recommend a visit by all
interested parties.

As I looked at the documents to be discussed at the upcoming ITU-T SG2 Working
Party 1 meeting (October 19-26, In Berlin, Germany), I found several documents
that, through discussion at the meeting should provide fruitful information for
our on-going work in ENUM.  Since access to the site is restricted to ITU
members, I will only reference titles and abstracts of contributions.
Specifically the following seem of interest:

Delayed Document #301, source: AT&T and LMGT
TITLE:    Overview of the IETF48 ENUM WG session from a WP1/2 perspective
Abstract
This document collects some aspects of the ENUM WG session from IETF48 of
interest to WSP1/2.  It also discusses documents and presentations by the
authors, and it includes additional information and pointers about ENUM.
Individuals participate in the IETF at a working level, and representing a
Member State or Sector Member is not applicable.  The views in this document are
offered in that spirit.

Delayed Document #304, source LMGT
TITLE:    Unofficial updated version of "E.164 number and DNS"
<draft-ietf-enum-e164-dns-03>
Abstract
This contribution is an unofficial update of "E.164 number and DNS"
<draft-ietf-enum-e164-dns-03>, an internet draft approved by the IESG as a
proposed standard.  It is provided for working purposes only.

Delayed Document #305; source LMGT and AT&T
TITLE:    Preliminary Assessment of ENUM Issues Relevant to WP1/2
Abstract
This contribution contains a preliminary assessment of ENUM issues relevant to
WP1/2.  It includes a list of issues, classification by scope, and next steps.
Other issues possibly arising from other sources are also considered.  This work
is intended to provide initial input and stimulate discussion.

Delayed Document #306; source: Telenor
TITLE:    Update of draft Rec.E.TIPI Naming, numbering and addressing for
interworking between E.164 and IP address-based networks
Scope: The Recommendation provides guidance for interworking between the E.164
and IP address-based networks, and identifies the users, service providers and
Administrations requirements to the naming options of this interworking. It
recommends the type of E.164 naming resources that should be made available to
IP address-based networks, and how these resources should be administered.

It identifies the addressing requirements to the involved E.164 and IP
address-based networks and the addressing space in the referred networks, and
recommends addressing schemes to be utilized in the E.164 address-based
networks.

Delayed Document #307, Source: NTT
TITLE:    Consideration of new draft recommendation E.TIPI
No abstract available

Delayed Document #309, source: AT&T
TITLE:    Administrative Requirements for Deployment of ENUM in North America
No abstract available

I would like to specifically thank the authors for compiling such a base of
knowledge for discussion at the meeting.  For example, #305 provides an
excellent listing and discussion of the kinds of issues that I was originally
referencing in my earlier message.  Also, #309 begins the discussion of the
administrative issues for a USA deployment of ENUM services, which will lay
groundwork for International deployment of ENUM services.  Andy Gallant, Steve
Lind and Penn Pfautz should be congratulated.  I will be most interested to hear
their comments regarding the results of the ITU discussions at the next IETF
meeting.

Regards,

Jay Hilton

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 13 Oct 2000 16:47:33 +0200

>proposed standard.  It is provided for working purposes only.

This is now published as RFC 2916, which can be found as 
http://www.ietf.org/rfc/rfc2916.txt.

    Patrik

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Fri, 13 Oct 2000 11:03:25 -0400

5. There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

Correct me if I'm wrong:  does this not apply to the U.S. SMS/800 systsem?

ie, that it "should be designed with adequate mechanisms for identification
and authentication of those requesting changes and for authorization of
those changes."?

Judith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Patrik Fältström
Sent: Friday, October 13, 2000 10:48 AM
To: Jay R. Hilton; [email-masked]
Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 13 Oct 2000 17:17:35 +0200

>and authentication of those requesting changes and for authorization of

Probably. Someone which knows what you mean by "SMS/800" system have 
to answer that. And also remember that we must in these discussions 
differ between local problems in one of the regions and the global 
issues.

The point with this text is that this is inside the security 
considerations section in the RFC, and as such it shows what security 
issues which the base technology does _not_ solve, but what can be 
enabled via the administrative systems around the technology 
describes.

I.e. updates are not discussed in this paper at all. That is handled 
either through DNS mechanisms (Dynamic DNS) or via out of band 
mechanisms (authenticated LDAP updates, or via secure http and some 
proper authentication or whatever the administrator finds ok).

   Patrik Fältström