[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
- [Enum] Re: URI Portability Stastny Richard
- RE: [Enum] Re: URI Portability Michael Hammer (mhammer)
- Re: [Enum] Re: URI Portability Stastny Richard
- RE: [Enum] Re: URI Portability Michael Hammer (mhammer)
- Re: [Enum] Re: URI Portability james.f.baskin
- Re: [Enum] Re: URI Portability Stastny Richard
- Re: [Enum] Re: URI Portability Otmar Lendl
- RE: [Enum] Re: URI Portability Tim Ruiz
- RE: [Enum] Re: URI Portability Michael Hammer (mhammer)
- Re: [Enum] Re: URI Portability Richard Shockey
- RE: [Enum] Re: URI Portability Michael Hammer (mhammer)
- Re: [Enum] Re: URI Portability Otmar Lendl
- Re: [Enum] Re: URI Portability Patrik Fältström
- Re: [Enum] Re: URI Portability Patrik Fältström
- [Enum] draft-ietf-enum-validation-token-01.txt Tony Rutkowski
- [Enum] Re: draft-ietf-enum-validation-token-01.txt Otmar Lendl
- [Enum] Re: draft-ietf-enum-validation-token-01.txt Tony Rutkowski