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

Otmar Lendl <lendl@nic.at> Tue, 21 February 2006 14:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYWc-0000VV-69; Tue, 21 Feb 2006 09:29:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYWa-0000VN-Hq for enum@ietf.org; Tue, 21 Feb 2006 09:29:56 -0500
Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBYWa-0004U7-4w for enum@ietf.org; Tue, 21 Feb 2006 09:29:56 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000) id BED0C1A487; Tue, 21 Feb 2006 15:29:53 +0100 (CET)
Date: Tue, 21 Feb 2006 15:29:53 +0100
From: Otmar Lendl <lendl@nic.at>
To: Tony Rutkowski <trutkowski@verisign.com>
Message-ID: <20060221142953.GG5755@nic.at>
References: <OFFD6D8F8B.8A667CF3-ON8525710F.005CB3F4-8525710F.005E1CEB@CORE.VERIZON.COM> <20060208174811.GA6329@nic.at> <7.0.1.0.2.20060216150317.02a9df20@verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7.0.1.0.2.20060216150317.02a9df20@verisign.com>
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: enum@ietf.org
Subject: [Enum] Re: draft-ietf-enum-validation-token-01.txt
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Hi Tony,

On 2006/02/16 15:02, Tony Rutkowski <trutkowski@verisign.com> wrote:
> 
> Your very useful token contribution can be
> usefully implemented within what seems the
> universal global architecture and process
> requirement for public ENUM.
> 
> Whoever is running the ENUM EPP bluebox
> will generally require four tokens.

Thank you for sharing your Authentication Architecture diagram.
Some comments/questions:

* Is this for User-ENUM?

* 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?

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

  Here in .at we had long discussions about that as well, and we
  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.

  For private persons that distinction may be unnecessary. For companies
  this can be an essential feature. E.g. if the numbers of all
  branch offices are managed from the headquarter: Validation is
  done through them, but you still want the local address in the
  phonebook. Or consider a holding with various brands.

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

* Concerning the Token from the "E.164 Service Subscriber": Is that
  one digitally signed? If yes, you need some sort of PKI. Who will
  act as the CA in that system?

* About the "referenced service provider": Are you sure you need a
  proactive agreement from that role? 

  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.

  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?


My plan was to get the token draft into WGLC as soon as possible
as all changes in the last 6 months were mostly cosmentic. 

I'd really like to accomodate any changes you might need. 

So: what are your requirements for the Token specs?

/ol
-- 
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

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