[Enum] Re: draft-ietf-enum-validation-token-01.txt

Hi Otmar,

>Thank you for sharing your Authentication Architecture diagram.
>Some comments/questions:
>
>* Is this for User-ENUM?

The relationships are applicable wherever an E.164 number
is used in providing services to the public.  Thus it
would apply to most of the various ENUM categories.

>* As I read the diagram, you plan to hold NAPTR records in your
>   Tier1(b) registry. You don't plan to do "normal" delegations
>   based on NS records?

My apologies for the confusion.  The architecture
was intended to apply at all registry tiers, although
for the upper tiers, some token functions would be
null.  There was no intent in the diagram to constrain
the hierarchical structures.

I should also underscore that this is just a "thought
piece" based on an array of current developments in
different industry, security, justice, and regulatory
forums worldwide.

>* You're planning to use the data from the ENUM validation to
>   feed the E.115 DBs?

Yes.  This would be necessary, for example, where E.164
number blocks are allocated directly to ISPs.  It also
gets a little tricky with number portability.  You need
some kind of authoritative E.164 directory and arguably
the protocol of choice is E.115v2 because of its nice
feature set and span of legacy and IP/NGN platforms.

>   decided against it. In our model, a new ENUM delegations contains
>   o The ENUM Token which documents the ownership of the number
>   and optionally
>   o a domain/number owner contact object which can be set by the registrar.
>   If we were to feed our data into a directory assistance DB, we'd
>   use the contact object and not the info from the Token.

I think you could do it either way, as long as the necessary
contractual agreements were put in place, and it was acceptable
by national authorities (regulatory, justice, security), including
telecom operators. :-)

>* I have some difficulties understanding the roles on the left side
>   of your diagram. Could you elaborate a bit on them?

You raise good questions, and I owe more narrative
on the diagram.  Again, it was largely to sort out
options for your very attractive token approach.

>   Nobody is doing that in the email space. I can point my MX records
>   to whomever I want to. I can install email forwards without
>   permission from the destination. I can do SIP redirects without
>   a token from the destination.

The new European Union Data Retention Directive will likely
alter the practices.

>   How much will this also introduce restriction on the SIP service
>   hosters? Can a Texan use a SIP provider based in Australia which
>   doesn't know a thing about your system?

I raised this issue in my presentation on the Directive
at ETSI three weeks ago.

>So: what are your requirements for the Token specs?

Forthcoming...

--tony

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum