Subject: RE: [Enum] fyi RE: I-D ACTION:draft-dommety-e212-dns-00.txt

From: "Gallant, Andy" <[email-masked]>
Date: Thu, 28 Jun 2001 04:58:18 -0400

See comments in line.  The final comment may be of
more general interest.

-Andy

-----Original Message-----
From: A.M.Rutkowski [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 8:59 AM
To: [email-masked]; [email-masked]
Subject: RE: [Enum] fyi RE: I-D ACTION:draft-dommety-e212-dns-00.txt

Hi John et al.,

>[MYH]  E.212 number is widely used.  Please check MAP spec.
>[<JAL> ] I believe that some text about this would be very helpful.  I do
>not think most IETF folks know MAP very well.  Also, it could be stated in
>more clear terms how MAP over IP (SIGTRAN for example) would need this kind
>of functionality.  Also, as SIP will be used in 3G networks, service
>identification via E.212 could also be useful.

There was considerable interest at the recent Berlin
Internet workshop in e212 as a namespace alternative
to e164.  

ag:  Any URLs for available workshop materials?

A number of people noted it doesn't have
the 50 years of legacy baggage as e164; 

ag:  See previous comment.

and it maps much
more cleanly to individuals and ancillary application
names (a fundamental flaw of e164).  

ag:  Not clear what this means.  In E.212, IMSIs are
     assigned to identify mobile terminals and/or mobile
     users.  See previous comment.

It also doesn't
invoke all the tier-1, tier-2,...tier-n nonsense currently
in vogue.

ag:  Not true.  IMSIs have 3 fields:  Mobile Country
     Code, Mobile Network Code, and Mobile Subscriber Identification
     Number.  Note that IMSIs already have a tiered structure.
     Note also that MCCs identify countries or may be shared
     by certain networks that meet ITU-defined criteria.
     Note finally that more than one MCC may identify
     a country, the rest of the resource is a national
     matter, and that Member States and Sector Members
     working in ITU-T Study Groups specified the criteria.

It can also fairly trivially easily point to e164 or
other identifiers NAPTR and other resource
records and even IP addresses using A RRs.  E212 may
be the ENUM namespace of choice by many providers
and users

ag:  Note that in theory, *any* set of alphanumeric
     strings *could be* the basis for an ENUM-like
     mapping (reverse string - separate characters
     with dots - prepend to suitable domain name).

     (As a thought experiment once, I constructed
     "ENAME" using a standard 26-letter alphabet
     instead of an alphabet of the 10 decimal 
     digits.  The mapping and protocol that resulted
     were exactly like those for ENUM as in RFC 2916
     (as expected), and there was no reason to
     write it up or do further formalistic work.)

     That(!) is the easy part.  All the rest, including
     the infrastructure of the infrastructure, will
     be just as complex as for ENUM, e.g., for E.212?, for
     those sets of strings that are identifiers and that
     have a significant meaning of their own outside
     the scope of the IETF and RFCs.

     So, the hard parts come from that "outside meaning"
     (which is the reason to use non-arbitrary identifiers
     in the first place) and from all the related mapping
     issues.  These include registration functions/entities
     and policies/procedures deriving from whatever it was
     that made these identifiers of value.

     To go from the sublime to possibly ludicrous, consider
     two other ITU "numbering" plans.  There's X.121 (used
     for example for X.25 data network terminal addresses).
     There's also F.69 (telex) - consider what web browsing
     would be like at telex speeds.  Should those plans
     be ENUMified for DNS-based implementation?

     The question, "Could E.212 be ENUMified?" is easy.
     The question, "Should E.212 be ENUMified?" is non-trivial.
     For the E.212 I-D, further information about intended
     use, related applications, administrative and coordination
     aspects, and other relevant matters would materially
     help with the second question.

     -Andy

--tony

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 28 Jun 2001 10:33:52 -0700

--On 01-06-28 04.58 -0400 "Gallant, Andy" <[email-masked]>
wrote:

>      That(!) is the easy part.

Another problem is though that what you grandfather for the grandfathering
to work have to be globally unique. A name of a person is not unique, so
grandfathering the names of persons doesn't help.

   paf