<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

[fwd: my comments to the SPAN list]

  • From:
  • Date: Thu, 24 Oct 2002 09:57:22 +0200

--- forwarded ---

From: axelm@localhost
To: Stastny Richard <Richard.Stastny@localhost
Cc: "SPAN11_nar : ETSI SPAN11_nar list" SPAN11_NAR@localhost,
  Lawrence Conroy lwc@localhost,
  Rudolf Brandner <Rudolf.Brandner@localhost, axelm@localhost
Subject: Re: Comments on ENUM Minimum Requirements

On (23.10.02 19:06), Stastny Richard wrote:
> -  6.3.: Perhaps the description of ENUM registrars could be something
>    like "ENUM registrars initiate delegations from the tier1 registry to
>    ENUM DNS providers (tier 2) on behalf of ENUM registrants (E.164
>    number owners). They interact with a validation agency to authorize 
>    and authenticate the registrant.
> 
>    Stastny: please add the proposed text and in addition:
>    The ENUM Registrar must provide a web-based interface to the ENUM end
> user
>    for registration and later modification of his registration data.
>    For identification and authentication userid and passwort is
> sufficient.

Let me suggest another version of the requirement for interaction
between ENUM registar and number assignee. I wouldn't focus on web, but
state something like:

"An ENUM Registrar must provide an interface to the ENUM end user for
modification and cease of his registration. An ENUM DNS
provider must provide an interface to the ENUM end user allowing to add,
change and delete the NAPTR (and probably other) DNS resource records
associated to his ENUM domain".

(in the trials, it is quite possible that those interfaces involve manual
interaction of end user and registrar)

Background of the second sentence: I wonder if web interfaces are first
choice for updates between number assignee and DNS provider. That's
probably true if updates are entered manually, but not neccessarily
applies if updates are done automatically, e.g. via the user's ENUM
client itself. In that case, a common automatic interface would be
desired. The propsed E.164-EPP-mapping
(http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-01.txt)
could be discussed as common base for such an interface.

A vision could be an IP-fax-application which updates NAPTR records 
of given numbers (using given credentials) automatically after
successful start of service ...

>    Stastny: Add to 6.7 something like this:
>    ENUM end users needs to be provided by the ENUM DNS Provider with an
> access 
>    to a web-base interface to allow the addition, deletion and
> modification of 
>    the (above mentioned) records in the zones associated with the
> registered 
>    E.164 numbers. 
>    For identification and authentication userid and passwort is
> sufficient.

see above comment for "web based".

>    Stastny: The reason for 9.1 was mainly DNAME. DNAME is needed if
>    one wants to "redirect" a whole tree (CNAME redirects only one zone).
>    We discussed this for number splits and parallel numbering. IMHO this
>    still requires further study and should not be included in the
> minimum requirements
>    (althouh I want to see a solution).
    
Yes, DNAME support was added in BIND9. But: DNAME is only neccessary if
you have such weird things like the "shortcut dial prefixes" of Austrian
cities (Vienna can be reached via the prefix "01", but also via "0222"). 

If you do deep delegations, this is only required at the tier1 level.
So, this requirement does not apply to tier2 name servers, which in turn
have of course to support the NAPTR record type.

So, i'd suggest "Tier1 Name servers should support DNAME record types if
national numbering plan includes [richard, please support a name for the
"vienna issue"]. Tier2 Name servers must support NAPTR record types."

that's it, for now, again.

Alex Mayrhofer

----- End forwarded message -----



  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>