[LINK] Enum musings

[Chirgwin, Richard]

Glen,

hang on...

> The ENUM proposal is to express E.164 (telephony) numbers
> using DNS as the database rather than SS7.  So the ultimate
> authority remains ITU, as they administer E.164 numbers.
> ITU in turn delegate number ranges to national or treaty
> administrations (such as the North American Numbering Plan).

I will read more, and check my facts: but as far as I know, the two are not
analogous. ITU numbering plans work differently to DNS in terms of
authority. And regardless of the "ultimate authority" for numbering formats,
the ultimate authority for the Enum DNS will not be the ITU. 

And the authority held in the DNS is important (which is why, I guess, ACA
and AARNET applied for Enum authority back in June). (However, I can find no
media announcement by either entity of the decision to apply for Enum
responsibility for Australia; not that I object to ACA or AARNET holding
this role, but both are public bodies, and the decision should be subject to
more scrutiny than seems to be the case.)

> I think I've made my point that there's a significant
> amount of regulatory work to be done, much more so than
> with domain names.

Yes. But now I'll return to what I said in the first message:
...Enum is half-baked, but
...its introduction is being accelerated with almost no consumer discussion.

What's the evidence of consumer "pull" that makes the rush necessary?

RC

> -----Original Message-----
> From: Glen Turner [mailto:glen.turner@aarnet.edu.au]
> Sent: Wednesday, 9 October 2002 11:39
> To: 'link@www.anu.edu.au'
> Subject: Re: [LINK] Enum musings
> 
> 
> Chirgwin, Richard wrote:
> 
> > So Enum says two things:
> > a) create a database in which an individual is identifiable by a DNS
> > registration; and
> > b) centralise administration of the hierarchy to ICANN. 
> 
> Hi Richard,
> 
> The ENUM proposal is to express E.164 (telephony) numbers
> using DNS as the database rather than SS7.  So the ultimate
> authority remains ITU, as they administer E.164 numbers.
> ITU in turn delegate number ranges to national or treaty
> administrations (such as the North American Numbering Plan).
> 
> > I'm not comfortable with that idea...to adopt it merely 
> because Enum enables
> > technical solutions is close to the cargo-cult mentality of 
> trading rights
> > for trinkets.
> 
> I won't disagree that there's a fair whack of cargo cult and
> gold rush mentality surrounding ENUM.
> 
> Jan wrote:
> 
>  > Question:  if ENUM can result in assignment of a 'telephone'
>  > number for someone/place without a phone, isn't that a waste
>  > of a limited resource? Didn't we just go through a phone
>  > number adjustment in the past 5 years to address this issue?
> 
> This is a major point.  There was a large real cost to the
> nationwide renumbering, and it's very economically unfair
> to non-ENUM users to do this again.
> 
> The alternative plan of making part of the number range
> longer will require some PABXs to be reprogrammed.  Even
> so, this is probably the better choice.
> 
> There's also an absolute length to E.164 numbers of 15 digits,
> including the country code, so it is only possible to add
> an additional three digits in any case (numbers are currently
> of the form 61 X XXXX XXXX).
> 
> Another numbering issue is that there's currently some legislative
> requirements on telcos that now should get moved to ENUM devices.
> For example, access to the long distance carrier selection prefix.
> This is currently handled in a few centralised SS7 databases.
> 
> Also note that some numbers you can dial on your phone are
> not E.164 numbers.  Prime amoung these is 000, which selects
> the 'intelligent services' function for the nearest operating
> emergency services call centre.  This 'numbering plan' information
> can be expressed in the ENUM DNS, but doing so means that
> you must resolve your DNS addresses via a DNS server in
> the country where you are located.  This wouldn't be the case
> for all Internet users at the moment, and obviously needs to be
> one of the enforced regulatory conditions on ENUM usage.
> 
> On the plus side, the 000 service currently uses a database
> relating number range to location.  When you are allocated a
> number range for your PABX the database is updated with the
> location that the PABX serves.  This is how the ambulance
> finds you if you dial 000 but cannot speak.
> 
> This database is slowly losing value, thanks to tie-lines,
> toll bypass and so on.  With ENUM each handset can have
> a DNS LOC (location) entry (which contains the lat,long,alt
> of the device).  This record is public, so there's another
> set of related policy issues if the ACA decide to enforce
> a LOC entry for each ENUM (not all bad outcomes, as current
> telephony users have no idea if their current location database
> entries are correct).
> 
> And that brings us back to DNS authentication and just who
> policy should allow to authenticate LOC records, and should
> there be a penalty attached to falsifying a LOC record.
> 
> I think I've made my point that there's a significant
> amount of regulatory work to be done, much more so than
> with domain names.
> 
> Cheers,
> Glen
> 
> 
> -- 
>   Glen Turner                                 Network Engineer
>   (08) 8303 3936      Australian Academic and Research Network
>   glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
> --
>   The revolution will not be televised, it will be digitised
> 
> ----------
> For Link list information see http://sunsite.anu.edu.au/link/
> 
----------
For Link list information see http://sunsite.anu.edu.au/link/