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

lconroy <lconroy@insensate.co.uk> Thu, 23 November 2006 17:32 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIQs-0006IT-Ub; Thu, 23 Nov 2006 12:32:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIQr-0006IJ-SP for enum@ietf.org; Thu, 23 Nov 2006 12:32:17 -0500
Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIQq-0003jl-F7 for enum@ietf.org; Thu, 23 Nov 2006 12:32:17 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5815F8C43E; Thu, 23 Nov 2006 17:32:05 +0000 (GMT)
In-Reply-To: <20061123165645.GA26860@nic.at>
References: <34DA635B184A644DA4588E260EC0A25A0E28DF4E@ACCLUST02EVS1.ugd.att.com> <200611231605.kANG5xbG005934@dragon.ariadne.com> <20061123165645.GA26860@nic.at>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <65AC5993-ED58-41D8-A9AC-7264B2F838AA@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs
Date: Thu, 23 Nov 2006 17:32:03 +0000
To: Otmar Lendl <lendl@nic.at>, NEO Pfautz Penn L <ppfautz@att.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: enum@ietf.org
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 Otmar, folks,
Me too. We were talking about ->E2U<- NAPTRs, right?
iENUM or (user) ENUM concentrates on NAPTRs using the
'E2U' DDDS application specified in RFC 3761. In effect,
it returns a universal name, not a routing ID. Routing
can and (IMHO) should be done elsewhere.

D2U/D2T/D2S NAPTR and SRV lookups as per RFC 3263 (almost
certainly in different zones) look like a much better way
to deal with any such source differentiated processing.

all the best,
   Lawrence

On 23 Nov 2006, at 16:56, Otmar Lendl wrote:
> 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


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