Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs

Otmar Lendl <lendl@nic.at> Thu, 23 November 2006 16:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHst-00026F-OP; Thu, 23 Nov 2006 11:57:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHsr-000267-Fc for enum@ietf.org; Thu, 23 Nov 2006 11:57:09 -0500
Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnHsn-0005vI-JZ for enum@ietf.org; Thu, 23 Nov 2006 11:57:09 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000) id F23064D0B1; Thu, 23 Nov 2006 17:56:45 +0100 (CET)
Date: Thu, 23 Nov 2006 17:56:45 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs
Message-ID: <20061123165645.GA26860@nic.at>
References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200611231605.kANG5xbG005934@dragon.ariadne.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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

On 2006/11/23 17:11, Dale.Worley@comcast.net wrote:
>    From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>
>
>    The requirement you propose is actually much different and, while
>    the initial (e.g., Tier 1) response may not be origin-sensitive,
>    further processing is likely to be since A carrier may have
>    different POIs for different interconnection partners.
>
> Hmmm... If that's so, you might want to add some explication of that
> in the requirements. The current definition suggests to the naive that
> the mapping from E.164 number to URI is offered to all comers .
>
> Indeed, from a technological point of view, it's a fairly complex
> feature to allow different mappings to be delivered to requests made
> on behalf of different originating parties.

I agree with Richard here: I-ENUM should return an AoR which act
as a "name" and does not contain source specific routing information.

It may well be that further processing is done on this AoR that leads
to different ingress points depending on the source network.

That, though, is out of scope for I-ENUM and thus need not be
mentioned in this document.

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

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