From enum-bounces@ietf.org Tue Jul 1 07:27:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629C93A6830; Tue, 1 Jul 2008 07:27:27 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD813A6830 for ; Tue, 1 Jul 2008 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y73jrSd-te-5 for ; Tue, 1 Jul 2008 07:27:26 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id B29BD3A6819 for ; Tue, 1 Jul 2008 07:27:25 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KDgpT-00043m-7C; Tue, 01 Jul 2008 16:27:35 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0AB397716AC; Tue, 1 Jul 2008 16:27:35 +0200 (CEST) Date: Tue, 1 Jul 2008 16:27:35 +0200 From: Peter Koch To: Ray.Bellis@nominet.org.uk Message-ID: <20080701142735.GB1594@unknown.office.denic.de> Mail-Followup-To: Ray.Bellis@nominet.org.uk, enum@ietf.org References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray, > > "Send-N" stuffs lots of metadata in the tree that I think doesn't > > belong there. > > As a DNS guy, do you see any mileage in Eleanor McHugh's suggestion of an > RR that could represent tree-depth information in *any* DNS tree? You mean this [quoting Eleanor McHugh]: >> You've identified an interesting problem: how to validate the depth/ >> shape of namespace tree branches allowed given an intermediary point >> on that tree. A general case solution using a new RR type could be >> useful in places other than just ENUM, and if that's the case your >> send-n proposal will either lead to the proliferation of copycat >> solutions in other hierarchies or else be an evolutionary dead-end >> when an RR does get defined. Therefore you have nothing to lose by >> proposing an appropriate RR in the first place. Well, I guess, I can say I share the academic interest, but I'm not sure this is in any way better than "send-n" except its generality. One could define a QTYPE that would return the number of empty non terminals at or below a node in the DNS tree. Still I don't agree with the need. > Yes, for the user it's the final digit time-out. When should the switch > decide "enough is enough, it's time to try an ENUM lookup"? Depending on the numbering plan determined by country prefix, it might be sufficient to suppress the first n queries, where n is, say, two more than the length of the area code being dialled. That would mean the client was able to identify the are code. But the ENUM lookups don't have to be blocking, so why not let the client send an ENUM query after every digit (see above for prefix/area code considerations)? > For the server it's a potential 5-fold reduction in the number of queries. > If your switches are doing this lookup for every telephone call that's a > *lot* of queries saved. In the best case, maybe, but you need the cooperation of the clients and you add a lot of complexity to the ENUM tree. I've still not seen a convincing argument that this query optimization is solving a real load problem. Apart from that, there's also lots of optimization opportunity in the client if you just let the client remember what a "full number" was; I've been told this is already done. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 1 07:34:50 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13093A67D6; Tue, 1 Jul 2008 07:34:49 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853593A67D6 for ; Tue, 1 Jul 2008 07:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTIlPJeA8zup for ; Tue, 1 Jul 2008 07:34:47 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 694633A63EC for ; Tue, 1 Jul 2008 07:34:47 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m61EYuVU007016Tue, 1 Jul 2008 14:34:57 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KDgwZ-000OT8-00; Tue, 01 Jul 2008 15:34:55 +0100 Date: Tue, 1 Jul 2008 15:34:55 +0100 From: "Clive D.W. Feather" To: Ray.Bellis@nominet.org.uk, enum@ietf.org Message-ID: <20080701143455.GD89909@finch-staff-1.thus.net> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080701142735.GB1594@unknown.office.denic.de> User-Agent: Mutt/1.5.3i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter Koch said: > But the ENUM lookups don't have to be blocking, > so why not let the client send an ENUM query after every digit (see above > for prefix/area code considerations)? Because it's still load on the servers that would be worth reducing. >> For the server it's a potential 5-fold reduction in the number of queries. >> If your switches are doing this lookup for every telephone call that's a >> *lot* of queries saved. > In the best case, maybe, but you need the cooperation of the clients As is true of many optimisation techniques. That shouldn't be an issue for this use case. > and you > add a lot of complexity to the ENUM tree. I don't see how you can describe this as "a lot". > Apart from that, there's also lots of optimization opportunity in the client > if you just let the client remember what a "full number" was; I've been > told this is already done. What do you mean by a "full number"? The whole problem is that it isn't a simple thing to determine. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 1 08:03:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAC63A689B; Tue, 1 Jul 2008 08:03:58 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2886A3A6852 for ; Tue, 1 Jul 2008 08:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixQHb-X0AbWs for ; Tue, 1 Jul 2008 08:03:57 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id BC8F33A67F1 for ; Tue, 1 Jul 2008 08:03:56 -0700 (PDT) Received: from [217.33.138.50] (account jim HELO [172.16.1.40]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 320613 for enum@ietf.org; Tue, 01 Jul 2008 16:04:05 +0100 Message-Id: From: Jim Reid To: IETF ENUM WG In-Reply-To: <20080701143455.GD89909@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 1 Jul 2008 16:02:58 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> X-Mailer: Apple Mail (2.926) Subject: [Enum] Re send-n for query optimisation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Jul 1, 2008, at 15:34, Clive D.W. Feather wrote: >> But the ENUM lookups don't have to be blocking, >> so why not let the client send an ENUM query after every digit (see >> above >> for prefix/area code considerations)? > > Because it's still load on the servers that would be worth reducing. I'm not sure that this load is ever likely to be significant in the overall scheme of things Clive. Is there any hard data here or are we all just working on guesses? How much query traffic could send-n actually save as a proportion of the overall number of DNS lookups that will be going on inside the NICC's private ENUM-like tree? I would assume that these lookups would be passing through some sort of resolving server, so there should be a Big Win for cache hits after the initial "priming" query. Mimimising queries and reducing load is always a Good Thing. Sometimes though the cost of doing that exceeds the benefit. It's not clear to me where the balance lies for send-n. It does seem a bit strange to propose a new NAPTR type to deal with a possible operational problem. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 1 10:11:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FC33A686C; Tue, 1 Jul 2008 10:11:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9783D3A69B3 for ; Tue, 1 Jul 2008 10:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82g22FV49LTU for ; Tue, 1 Jul 2008 10:11:05 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 8055F3A686C for ; Tue, 1 Jul 2008 10:11:05 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KDjNo-0006TA-Pi; Tue, 01 Jul 2008 19:11:12 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 92FB7771F85; Tue, 1 Jul 2008 19:11:13 +0200 (CEST) Date: Tue, 1 Jul 2008 19:11:13 +0200 From: Peter Koch To: "Clive D.W. Feather" Message-ID: <20080701171113.GE1594@unknown.office.denic.de> Mail-Followup-To: "Clive D.W. Feather" , enum@ietf.org References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080701143455.GD89909@finch-staff-1.thus.net> User-Agent: Mutt/1.4.2.1i Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Tue, Jul 01, 2008 at 03:34:55PM +0100, Clive D.W. Feather wrote: > Because it's still load on the servers that would be worth reducing. at least me would feel much more comfortable if this claim was substantiated by facts, figures, measurements. > > In the best case, maybe, but you need the cooperation of the clients > > As is true of many optimisation techniques. That shouldn't be an issue for > this use case. Only if you can sanction non-optimizing clients; otehrwise the (perceived, so far) gain only benefits the server, so why would the client dare to implement the optional send-n feature? > > add a lot of complexity to the ENUM tree. > > I don't see how you can describe this as "a lot". Adding a NAPTR for a significant fraction of all empty non terminals? Thereby sacrificing the additional information that "ENT" might have given you? > > if you just let the client remember what a "full number" was; I've been > > told this is already done. > > What do you mean by a "full number"? The whole problem is that it isn't a > simple thing to determine. It is, once you succeded to placing a call there. If the client (or the PBX) remembers a list of dialed numbers, you can follow the digits until you either match the number again or until you find the first differing digit. Of course, that's a client "cooperation", as well. And from what we've heard so far, it might not work well in AT. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 2 14:38:51 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D083F3A6833; Wed, 2 Jul 2008 14:38:51 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67B23A6833 for ; Wed, 2 Jul 2008 14:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isrYwdoQ2vdW for ; Wed, 2 Jul 2008 14:38:49 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 6DDE83A63D2 for ; Wed, 2 Jul 2008 14:38:48 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=CfUKiT1f6EvNcIdggHlHxK3DRtQJkdabeVAjL+Od+2dYLpu3Ta1oHtqz GiuF78dTU5R+/F6ylCehnUeKM/4lJ1W9HVctD70K/NRHQQIENWikw09Me 5sj5qnF7ZmoCg1P; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215034739; x=1246570739; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Se nd-n,=20=20rat=20holes=20and=20real=20issues|Date:=20Wed, =202=20Jul=202008=2022:38:56=20+0100|Message-ID:=20|To:=20enum@ietf.org|MIME-Version:=201.0; bh=Pqb68GWQMQ5NSTe5Gla+a/ofcDZu58wO47FCnOUgBAo=; b=n6EKUTb3SCN8kqN5g+SDD017AjGz9xgikIprJyFS816RchSRR53qCk3n XnhhhxfBs73uXfJSD0RVMaFcf9CObNcZ6Ru9AH2xlRWMRU9nofPTY1EU3 X0Cwwl699GCxKbg; X-IronPort-AV: E=Sophos;i="4.27,739,1204502400"; d="scan'208";a="3865372" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 02 Jul 2008 22:38:57 +0100 To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Wed, 2 Jul 2008 22:38:56 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/07/2008 10:38:56 PM, Serialize complete at 02/07/2008 10:38:56 PM Subject: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org It appears to me that this discussion is actually getting somewhere sensible. The following rat holes appear to have been exposed as bogus: 1. This is not /just/ about a fully populated tree for a national number space. If you take a different example, like a tree of only ported numbers, or a private tree shared by a group of carriers then it does not matter what the regulator knows. In those cases the shape of the tree is determined by the data that is put in it and _solely_ by the data put in it, so no outside data representation is of any use. Protocols that describe the dial plan or numbering plan are orthogonal to this draft. 2. The views of some people that overlapped dialling should not be used cannot be tackled by this draft. It exists, it is used and that is that. 3. According to all the DNS experts the treatment of wildcards is not an issue. So that leaves us with the following real issues that are actually worth discussing. The first two are more about DNS: a. Whether or not we need a more general mechanism to describe the shape of the tree rather than the something just for ENUM? Also expressed as whether there should be meta-data in the tree about the tree (and whether NAPTR is a good way to do that)? b. What is the trust/security implication from one label in the tree making a statement about later labels in the tree even though they might be under different administrative control? and the second two are specifically about send-n: c. Is the relative form of send-n worth the trouble? d. Is the trade off between extra records vs reduced lookups worth it? Any more real issues? Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 2 15:47:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC793A6CA2; Wed, 2 Jul 2008 15:47:58 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E95E3A6CA2 for ; Wed, 2 Jul 2008 15:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV7hGJQDUcKT for ; Wed, 2 Jul 2008 15:47:56 -0700 (PDT) Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 9551E3A6C7B for ; Wed, 2 Jul 2008 15:47:55 -0700 (PDT) Received: from [192.168.1.103] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m62Mlsm3088549; Wed, 2 Jul 2008 18:47:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080630160805.GK487@unknown.office.denic.de> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> Date: Wed, 2 Jul 2008 18:45:29 -0400 To: Peter Koch From: Edward Lewis X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Cc: IETF ENUM WG Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 18:08 +0200 6/30/08, Peter Koch wrote: >understood. Since that is an optimization for a provisioning issue of >- to me - unclear frequency of occurence, would much be lost with using >the absolute value only? I'm responding to Peter's message to amplify at least to very good points he made. This is one of them. When I read the draft, I was first shocked at the choice of a relative number in the record. My mind shot back in time to the debates over the IPv6 records for addresses, namely the AAAA record (and PTR for reverse) and the A6 record (with something called bit labels for the reverse). The former was the already defined, static absolute approach, the latter an up and coming relative approach, all the rage at the time (2001). The benefits of A6/bit labels were that it was helpful in network renumbering, that is, if the (IPv6 network) prefix changed the local part could remain the same. The change would have very little impact on the provisioned data in the DNS. The drawbacks became evident when the experts tried to explain how this worked on the chalkboard. I never saw anyone walk through an entire, non-trivial example without a serious error. That is, it was confusing for even an expert (much less a field engineer debugging a live system). Secondly, with some carefully crafted entries, it was possible to tie up the resolution process in a nearly endless cycle of queries and assemblies of addresses. I should point out that some of the drawbacks were unique to the A6/bit labels. This is because it was the DNS as client in the lookup process. With the send-n use case, the DNS is only on the server side and wouldn't suffer. Still, to this day relative offsets carry red flags as there is a potential for errors to pop up in the ENUM clients. This is why my knee-jerk reaction is to suggest that absolute numbers be used. A little pain in the provisioning side will save a lot of suffering on the resolution side. DNS's great strength is the resolution side, don't hamper it! >Inter-digit timeouts, as far as I understand, would bite the dialing customer >at the end of their dialing process because only after the timer's >expiration would the full number be submitted to the ENUM lookup mechanism. >But since the human can't dial at light speed - where's the gain in terms >of latency over just querying after each digit pressed? This isn't a DNS topic (referring to Peter's title as DNSOP chair as representative of one of his fields of expertise), his words echo my thoughts as I read the draft. I do know that there are times I half dial a number and then have to squint again at a piece of paper, but it is usually apparent when the dialing is over. Further, telephone dialing is so slow now, I wouldn't know if there was a longer delay "just to make sure" I was done dialing. >Apologies. NAPTR is becoming the TXT RR for enum; everything can be put Back to the DNS side of the house, this is another opinion of Peter's I will second. If you want to put a dialing plan in the DNS, just use TXT records and store it somewhere else! The NAPTR has two outcomes - rewriting the URI you are trying to resolve or redirecting your DNS lookup. Using it to convey data about the data model, well, it may be possible, but not in the scope of the NAPTR mission. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 2 16:17:46 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07793A6A68; Wed, 2 Jul 2008 16:17:46 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99AE53A69E0 for ; Wed, 2 Jul 2008 16:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZfFSnsDttpw for ; Wed, 2 Jul 2008 16:17:44 -0700 (PDT) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 8DEF33A6998 for ; Wed, 2 Jul 2008 16:17:44 -0700 (PDT) Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KEBaC-000225-Gv for enum@ietf.org; Thu, 03 Jul 2008 00:17:52 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1KEBaC-0005t7-2z for enum@ietf.org; Thu, 03 Jul 2008 00:17:52 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 0A48E1A9ADB0 for ; Thu, 3 Jul 2008 00:20:49 +0100 (BST) Message-Id: <6DDC486B-FEDF-4DF6-A633-F24AADC9EB96@games-with-brains.com> From: Eleanor McHugh To: enum@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Jul 2008 00:17:51 +0100 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2 Jul 2008, at 22:38, Jay Daley wrote: > So that leaves us with the following real issues that are actually > worth > discussing. The first two are more about DNS: > > a. Whether or not we need a more general mechanism to describe the > shape > of the tree rather than the something just for ENUM? Also expressed > as > whether there should be meta-data in the tree about the tree (and > whether > NAPTR is a good way to do that)? > > b. What is the trust/security implication from one label in the tree > making a statement about later labels in the tree even though they > might > be under different administrative control? > > > and the second two are specifically about send-n: > > c. Is the relative form of send-n worth the trouble? > > d. Is the trade off between extra records vs reduced lookups worth it? > > > Any more real issues? e. This is probably covered by point (b) above, but I think it needs explicit consideration: if a NAPTR is being used (a la send-n), what are the implications of non-terminals and should they be restricted? Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 2 19:22:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6AE3A67C0; Wed, 2 Jul 2008 19:22:22 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656B53A67C0 for ; Wed, 2 Jul 2008 19:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPzb2dITH4Jh for ; Wed, 2 Jul 2008 19:22:19 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 738E43A63D2 for ; Wed, 2 Jul 2008 19:22:19 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEESX-0003EW-5v; Wed, 02 Jul 2008 21:22:16 -0500 From: "Brian Rosen" To: "'Jay Daley'" , References: Date: Wed, 2 Jul 2008 22:22:12 -0400 Message-ID: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjcjAbwTYAuQwcKS6i04arrxhDlQAAJoWmg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I claim this should be about determining the length of numbers, and not a solution to overlapped dialing. The length of the number 99% of the time is totally a function of a regulator. The other 1% of the time, the regulator allocates a prefix, and a carrier, or in some cases an enterprise, determines the length of the suffix. We need a solution for that 1%, but it's 1% and the 1% probably ought to not be the tail wagging the dog. While I understand that this draft proposes a way for someone to get a number length out of an ENUM tree, I propose that we solve the general problem, which I believe is an acceptable solution applicable to the overlapped dialing problem. I'm not fussy about what the solution look like, although I want it to be useful to the entity creating an ENUM tree as well as an entity using ENUM. Brian > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Jay Daley > Sent: Wednesday, July 02, 2008 5:39 PM > To: enum@ietf.org > Subject: [Enum] Send-n, rat holes and real issues > > It appears to me that this discussion is actually getting somewhere > sensible. The following rat holes appear to have been exposed as bogus: > > 1. This is not /just/ about a fully populated tree for a national number > space. If you take a different example, like a tree of only ported > numbers, or a private tree shared by a group of carriers then it does not > matter what the regulator knows. > > In those cases the shape of the tree is determined by the data that is put > in it and _solely_ by the data put in it, so no outside data > representation is of any use. Protocols that describe the dial plan or > numbering plan are orthogonal to this draft. > > 2. The views of some people that overlapped dialling should not be used > cannot be tackled by this draft. It exists, it is used and that is that. > > 3. According to all the DNS experts the treatment of wildcards is not an > issue. > > > > So that leaves us with the following real issues that are actually worth > discussing. The first two are more about DNS: > > a. Whether or not we need a more general mechanism to describe the shape > of the tree rather than the something just for ENUM? Also expressed as > whether there should be meta-data in the tree about the tree (and whether > NAPTR is a good way to do that)? > > b. What is the trust/security implication from one label in the tree > making a statement about later labels in the tree even though they might > be under different administrative control? > > > and the second two are specifically about send-n: > > c. Is the relative form of send-n worth the trouble? > > d. Is the trade off between extra records vs reduced lookups worth it? > > > Any more real issues? > > Jay > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 00:47:54 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CAB3A6BEC; Thu, 3 Jul 2008 00:47:54 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F443A67B0 for ; Thu, 3 Jul 2008 00:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSFBgDnTQBA0 for ; Thu, 3 Jul 2008 00:47:51 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 811D03A6B08 for ; Thu, 3 Jul 2008 00:47:50 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=04bu4aAuC0nPz8ztyo6/STYv+p79DmXimVRI+lwa64QLcFSsKWxVFCPV 8inYJDeAPIAW6Z3ASfrRkIxjwVeYU7uMEbIVZg3N/FCIsy+R55yuwBbpX AhFdTVrYYCPfMtz; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215071280; x=1246607280; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-n,=20=20rat=20holes=20and=20real=20issues|Date: =20Thu,=203=20Jul=202008=2008:47:57=20+0100|Message-ID: =20|To:=20enum@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<6DDC486B-FEDF-4DF6-A633-F24AADC9EB96@ games-with-brains.com>|References:=20=20 <6DDC486B-FEDF-4DF6-A633-F24AADC9EB96@games-with-brains.c om>; bh=PtTtb72fPJa/NyEOFF3j7kuQS/nzzUJt8tNrnmYxVjQ=; b=YzVH1FyhbxMDWB+eC/ZjxZaqa4fBnxEzuiMDgN/Zy6WYQAu5nGLpUqiC xlCUXYY2+grv4hGkec2BdiCQUzp4fkjqh169Ycgi8ZcW1DEs89XjI1Cqv +iUHI0t/H7vTTE+; X-IronPort-AV: E=Sophos;i="4.27,740,1204502400"; d="scan'208";a="4708217" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jul 2008 08:47:58 +0100 In-Reply-To: <6DDC486B-FEDF-4DF6-A633-F24AADC9EB96@games-with-brains.com> References: <6DDC486B-FEDF-4DF6-A633-F24AADC9EB96@games-with-brains.com> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 3 Jul 2008 08:47:57 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 08:47:57 AM, Serialize complete at 03/07/2008 08:47:57 AM Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > e. This is probably covered by point (b) above, but I think it needs > explicit consideration: if a NAPTR is being used (a la send-n), what > are the implications of non-terminals and should they be restricted? Yes, if NAPTRs are used for Send-N then they should not be used in non-terminal NAPTRs. That's currently implicit in the draft (as indeed it appears to be in Richard's CNAM draft) because the only valid form for a Send-N is as described in the regexp field. I'll make it more explicit. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 02:07:35 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0803A68C2; Thu, 3 Jul 2008 02:07:35 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5303A68C2 for ; Thu, 3 Jul 2008 02:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVjMVvxlJPGa for ; Thu, 3 Jul 2008 02:07:34 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B2B523A68BD for ; Thu, 3 Jul 2008 02:07:33 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=CX9/H0d4VADgW5EKkmPy3Yb9MjsIENx08GPT41J5MkKL8ebPrlHOUdwl Jci0HPDFOSiJRwX+oRzeRD0IdEQqDzP56/qO7vp9c4PjvsR5km6qkPx/F 6ShurqM7rX3Urzh; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215076063; x=1246612063; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Jay=20Daley"=20|Subject:=20 Re:=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20is sues|Date:=20Thu,=203=20Jul=202008=2010:07:30=20+0100 |Message-ID:=20|To:=20"Brian=20Rosen"=20 |Cc:=20|MIME-Version: =201.0|In-Reply-To:=20<018901c8dcb3$9f3f1f70$e76af444@cis .neustar.com>|References:=20=20<018901c8 dcb3$9f3f1f70$e76af444@cis.neustar.com>; bh=xjJysTjQDDpnjuKoozBDdPSmhwaYcR5Jb0L6E58/W9s=; b=S/N0bpWG/cxCRrWY/g7UOclQ2CXqO1ZO8PsQB8+QFrGAq+omlWMMjHEg kjOWZuNovTKpxw2dlhhrZiFtCO+1KhAzM2cPrgw9E8rPnpJcExH7e46gk HqBfsx+d3aootuv; X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="3875996" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2008 10:07:41 +0100 In-Reply-To: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Jay Daley" Date: Thu, 3 Jul 2008 10:07:30 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 10:07:41 AM, Serialize complete at 03/07/2008 10:07:41 AM Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian > I claim this should be about determining the length of numbers, and not a > solution to overlapped dialing. [rest snipped] Apologies in advance if this comes across as rude, I don't mean it to. You've presented this view several times now and on at least a couple of those occasions a reply has been given explaining why your view is about something quite different from send-n, except in one edge case. Yet it doesn't appear that you have addressed that response. So I'm going to have one more go at explaining this and I would really appreciate you responding to this rather than restating your view. 1. There are a number of different types of ENUM tree out there in use. They include: a) National full number trees, fully populated (or almost) according to a national numbering plan b) National user trees, scarcely populated with no algorithmic or other descriptive means of saying what numbers are in the tree. c) National number portability trees, partially populated. Again with no descriptive means of saying what numbers are in the tree. d) Inter-carrier trees, be definition only partially populated and both with and without external descriptions of what numbers are in the tree. e) Lots of other private trees. 2. The only type of tree from the list above where the type of plan you are proposing would obviate the need for send-n is a). In all the other cases, because the tree is not fully populated, only a description of what numbers are _actually_ in the tree is of any use. 3. You could of course maintain a separate database for b) and c) with a list of all numbers in the tree, using something like the protocol you propose, but I am hoping you are not proposing that because the duplication of effort, processing overhead and overall complexity would be astonishing. 4. I agree totally that we need a the type of protocol that you are proposing. In fact I think it would be very valuable, more so than send-n, and I am willing to commit resources to work on it with you if you wish. However it is still completely orthogonal to send-n. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 04:13:38 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597033A6A11; Thu, 3 Jul 2008 04:13:38 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC503A6908 for ; Thu, 3 Jul 2008 04:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNe38arG2r67 for ; Thu, 3 Jul 2008 04:13:35 -0700 (PDT) Received: from mail157.messagelabs.com (mail157.messagelabs.com [85.158.136.211]) by core3.amsl.com (Postfix) with SMTP id 373B23A68BD for ; Thu, 3 Jul 2008 04:13:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-3.tower-157.messagelabs.com!1215083604!15397653!3 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 23680 invoked from network); 3 Jul 2008 11:13:41 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-3.tower-157.messagelabs.com with SMTP; 3 Jul 2008 11:13:41 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 12:13:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 12:13:28 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues thread-index: AcjcjAz12UYizlXWQq2hHRyUKhSrTAAbjeeQ From: "Rosbotham, Paul" To: "Jay Daley" , X-OriginalArrivalTime: 03 Jul 2008 11:13:29.0527 (UTC) FILETIME=[D26D3C70:01C8DCFD] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I can only speak from the perspective of having a variable length dialling plan nationally, and having to deal with complex number length tables internationally. I'm no DNS expert so this is from a requirements perspective; > > and the second two are specifically about send-n: > > c. Is the relative form of send-n worth the trouble? The relative form arose partially from a standpoint of simplifying renumbering, but more for historic reasons. Our UK variant of C7 has the concept of SND(n), which terminating switches send back to originating switches when the number length is insufficient, asking for n more digits. The concept of SEND-N in DNS was devised to mimic that, albeit with a database (DNS) providing the info rather than the terminating node. Since SND(n) gave the number of extra digits needed, SEND-N did the same, in order to keep the call handling engine the same. If it causes issues, I wouldn't die in a ditch about it. > > d. Is the trade off between extra records vs reduced lookups worth it? > Given the hassle of maintaining the number length tables, I'd say an emphatic yes. It's all very well saying ENUM is specified to be queried with a complete number, but that's precious little use if you've no idea whether the number you've got is complete or not. Take a look at Section 3.3 of http://www.nicc.org.uk/nicc-public/Public/guidelines/nd1423_2007_06.pdf , which provides an overview of number lengths in some countries and it'll become clear how complex that is. Regretably, regulators (more properly numbering plan administrators) aren't always the best at publishing correct information hence there's various international informal circles of databuild guys continually trying to update the pieces of the jigsaw (not to mention commercial organisations who'll help for a fee). I know there's information at the ITU-T website...as it happens I initiated that about 7 or 8 years ago...but it's far from comprehensive. So in a fully populated ENUM situation incorporating number length info seems a pragmatic way forward. In a partially populated situation as you subsequently described, it seems to me even more so. What matters is the length of the numbers in there, not the theoretical length of numbers that would plug the gaps. > > Any more real issues? > > Jay > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 04:23:35 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33BC3A6864; Thu, 3 Jul 2008 04:23:35 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5C13A687F for ; Thu, 3 Jul 2008 04:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1paAzMStIuF for ; Thu, 3 Jul 2008 04:23:33 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 9272E3A681B for ; Thu, 3 Jul 2008 04:23:33 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 19A7DFF26D; Thu, 3 Jul 2008 21:23:40 +1000 (EST) Message-ID: <486CB688.9080502@e164.org> Date: Thu, 03 Jul 2008 21:22:48 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "Rosbotham, Paul" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Cc: Jay Daley , enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > The relative form arose partially from a standpoint of simplifying > renumbering, but more for historic reasons. Our UK variant of C7 has > the concept of SND(n), which terminating switches send back to > originating switches when the number length is insufficient, asking > for n more digits. The concept of SEND-N in DNS was devised to mimic > that, albeit with a database (DNS) providing the info rather than the > terminating node. Since SND(n) gave the number of extra digits > needed, SEND-N did the same, in order to keep the call handling > engine the same. If it causes issues, I wouldn't die in a ditch > about it. Just because that's what happened in the past is no reason to keep doing the same thing if there is better ways to achieve the same result. > Given the hassle of maintaining the number length tables, I'd say an > emphatic yes. It's all very well saying ENUM is specified to be > queried with a complete number, but that's precious little use if > you've no idea whether the number you've got is complete or not. > Take a look at Section 3.3 of > http://www.nicc.org.uk/nicc-public/Public/guidelines/nd1423_2007_06.pdf > , which provides an overview of number lengths in some countries and > it'll become clear how complex that is. Regretably, regulators (more > properly numbering plan administrators) aren't always the best at > publishing correct information hence there's various international > informal circles of databuild guys continually trying to update the > pieces of the jigsaw (not to mention commercial organisations who'll > help for a fee). I know there's information at the ITU-T > website...as it happens I initiated that about 7 or 8 years ago...but > it's far from comprehensive. So in a fully populated ENUM situation > incorporating nu mber length info seems a pragmatic way forward. > > In a partially populated situation as you subsequently described, it > seems to me even more so. What matters is the length of the numbers > in there, not the theoretical length of numbers that would plug the > gaps. Again, where is the flaw in using a BGP like distributed routing table, this would seem to be the most efficient to me, since nothing would need to make any requests until the internal dial plan conditions were met. The only data broad casted outwards would be incremental updates as information changes, rather than keep banging away at DNS requests until everything is satisfied that the full number is done. Unlike TRIP this shouldn't be used to update route costs as well, a very very simple protocol carrying just the numbering length. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 05:47:35 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11D23A6809; Thu, 3 Jul 2008 05:47:35 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE8F3A6864; Thu, 3 Jul 2008 05:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-yCr58Eyrs9; Thu, 3 Jul 2008 05:47:34 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 928633A67A6; Thu, 3 Jul 2008 05:47:33 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=QM5S4hhSOArWEbZFAha4CFWxfAA5E81J7g/aTAKC1K22umNgLvEbf+op 70lqXEXArA38yOpDQyM5X6hLcUpaiA5Yq18qlVL36vgJ53iy4stBJU3/y YDeg9kNAB1p36sJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215089263; x=1246625263; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Thu,=203=20Jul=202008=2013:47:40=20+0100 |Message-ID:=20|To:=20enum@ietf.org|Cc: =20IETF=20ENUM=20WG=20,=0D=0A=09enum-bounc es@ietf.org|MIME-Version:=201.0|In-Reply-To:=20<200806301 60805.GK487@unknown.office.denic.de>|References:=20<48657 FC5.2010205@e164.org>=09=0D=0A=09<200806 29132325.GA23998@x27.adm.denic.de>=09=20 <20080630160805.GK487@unknown.office.denic.de>; bh=D8PIrf6dq8t2R1fY2MfwGcu15UgXOrm3YBrzLPTKb34=; b=3Yt0B93F6rs9K13GZJuwQ0zeccRzZm5mooGDVOdlKXkd2snH5bvHZ3NP XW9IiVRYwCpSf07zWEZC8G/43bB+Ut5rS/ELvErVbJCnBeT2sjiKAQURJ QuA5EFWu/JrNIVG; X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="4715761" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jul 2008 13:47:41 +0100 In-Reply-To: <20080630160805.GK487@unknown.office.denic.de> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> To: enum@ietf.org Cc: IETF ENUM WG , enum-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 3 Jul 2008 13:47:40 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 01:47:40 PM, Serialize complete at 03/07/2008 01:47:40 PM Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter - following up this comment again: > Apologies. NAPTR is becoming the TXT RR for enum; everything can be put > in there so conveniently, especially using "data" type URIs. That's not > what NAPTR was designed for. I wonder where this concern about NAPTR becoming a dumping ground for data has come from? The whole DDDS architecture is *supposed* to be a generic database lookup system, albeit one that has its origins in ENUM. The only implementation of DDDS that I'm aware of is RFC3403, and *that* is what specifies NAPTR records, not the ENUM RFCs. One *could* write a Send-N U-NAPTR Application that sits in its own DNS tree that happens to represent the structure of some other DNS tree. That might not be so controversial, but it would *still* be using NAPTR records. As it happens, though, it's actually possible to put the data in the *same* DNS tree, albeit there are a couple of special edge cases that have to be taken into consideration. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 06:04:09 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2953A67EB; Thu, 3 Jul 2008 06:04:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DF03A67EB for ; Thu, 3 Jul 2008 06:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY9SFvASTdc3 for ; Thu, 3 Jul 2008 06:04:02 -0700 (PDT) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 91CEE3A67A6 for ; Thu, 3 Jul 2008 06:04:00 -0700 (PDT) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KEOTm-00017B-G5 for enum@ietf.org; Thu, 03 Jul 2008 14:04:07 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1KEOTW-00029X-27 for enum@ietf.org; Thu, 03 Jul 2008 14:03:50 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 5F5051AAEA23 for ; Thu, 3 Jul 2008 14:06:48 +0100 (BST) Message-Id: <37A42700-153F-433C-9262-5D3C4B7BEBB7@games-with-brains.com> From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Jul 2008 14:03:49 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 3 Jul 2008, at 13:47, Ray.Bellis@nominet.org.uk wrote: > Peter - following up this comment again: > >> Apologies. NAPTR is becoming the TXT RR for enum; everything can >> be put >> in there so conveniently, especially using "data" type URIs. >> That's not >> what NAPTR was designed for. > > I wonder where this concern about NAPTR becoming a dumping ground > for data > has come from? > > The whole DDDS architecture is *supposed* to be a generic database > lookup > system, albeit one that has its origins in ENUM. The only > implementation > of DDDS that I'm aware of is RFC3403, and *that* is what specifies > NAPTR > records, not the ENUM RFCs. > > One *could* write a Send-N U-NAPTR Application that sits in its own > DNS > tree that happens to represent the structure of some other DNS > tree. That > might not be so controversial, but it would *still* be using NAPTR > records. > > As it happens, though, it's actually possible to put the data in the > *same* DNS tree, albeit there are a couple of special edge cases > that have > to be taken into consideration. This probably isn't the time or place to mention it (and apologies to those of you who've sat through discussion of these in the company of beer) but NAPTRs can be used for all kinds of fun purposes once you start thinking of them as generic production rules or s-expressions: URI validation; cross-service API translation and aggregation; relational data stores; multi-directional hyperlinks; all kinds of fun stuff. I wouldn't necessarily advocate any of these as real world applications mind as they're outside the scope of DNS's core purpose, but it is amazing just how flexible a tool the U-NAPTR can be. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 06:33:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66E33A6864; Thu, 3 Jul 2008 06:33:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD73A6864; Thu, 3 Jul 2008 06:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs26Y9hk147b; Thu, 3 Jul 2008 06:33:03 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 9C0D53A67A6; Thu, 3 Jul 2008 06:33:02 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id D09BBA5614; Thu, 3 Jul 2008 14:33:10 +0100 (BST) Message-Id: <72668D83-E6B3-4C66-AA5C-5E9CF6375182@insensate.co.uk> From: Lawrence Conroy To: Ray.Bellis@nominet.org.uk In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 3 Jul 2008 14:33:10 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org, enum-bounces@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Ray, folks, Speaking of red herrings... Re. D3S as a dump - are TXT records better than NAPTRs? ROFL AFAICT, the logic here is that NAPTRs hold PoinTeRs, whilst data: allows "final" data to be inserted. Then again, so does pstndata:. The names have been changed, but the story is the same. It seems to me that Send-N is *NOT* final data to be processed, but merely holds meta-data to assist in the process. Whether that meta-data in Send-N is useful or needed in practice is a reasonable question, but arguing that this is the same as replacing TXT with NAPTRs (or that TXT is better) is not, IMHO. Re. NTNs - these will have the effect of causing another lookup - that's what they're intended to do. IMHO, there should be NO other impact at all. You might want to point out that extra lookups are bad as they do cause delays/extra traffic, but that is a general issue for infrastructure use. Send-N seems to me to be no different. There will either be an NTN loop or there will (eventually) be a target domain. That target domain either includes E2U NAPTRs or it doesn't. You process those E2U NAPTRs or give up. Done. This is bog standard stuff and is the case for any D3S application. Regarding "collision avoidance" - this is covered in 3402 section 5, in 3403 section 3, and in 3761 section 2.4.2. Why on earth would one need to cover it again in this Enumservice Specification unless it is a particular problem for Send-N? I don't believe that is the case. I would be surprised if anyone provisioned these in DNS node that also had NAPTRs from other D3S applications - ENUM uses its separate tree as one means for collision avoidance, and that's is broken if U-NAPTRs or 3263- style NAPTRs are put there. Regarding whether NAPTRs or another RR type should be used - NAPTRs seem to have been chosen as there isn't a need for a further lookup once a terminal node has been reached - any extraneous Send-N NAPTRs come along for the ride when looking up a URI for communications. Thus for correctly entered numbers, only one ENUM query is made. That's good, IMHO. Please let's focus on whether or not Send-N solves a problem, whether the cure is worse than the disease, and whether the particular URI form is appropriate. The rest of this thread is going to make the (Outside) Dublin meeting go on for days, and we have only an hour :(. all the best, Lawrence On 3 Jul 2008, at 13:47, Ray.Bellis@nominet.org.uk wrote: > Peter - following up this comment again: >> Apologies. NAPTR is becoming the TXT RR for enum; everything can >> be put >> in there so conveniently, especially using "data" type URIs. >> That's not >> what NAPTR was designed for. > > I wonder where this concern about NAPTR becoming a dumping ground > for data > has come from? > > The whole DDDS architecture is *supposed* to be a generic database > lookup > system, albeit one that has its origins in ENUM. The only > implementation > of DDDS that I'm aware of is RFC3403, and *that* is what specifies > NAPTR > records, not the ENUM RFCs. > > One *could* write a Send-N U-NAPTR Application that sits in its own > DNS > tree that happens to represent the structure of some other DNS > tree. That > might not be so controversial, but it would *still* be using NAPTR > records. > > As it happens, though, it's actually possible to put the data in the > *same* DNS tree, albeit there are a couple of special edge cases > that have > to be taken into consideration. > > Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 07:44:55 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712B53A69AE; Thu, 3 Jul 2008 07:44:55 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255823A69AE for ; Thu, 3 Jul 2008 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBJz84vN-yvS for ; Thu, 3 Jul 2008 07:44:53 -0700 (PDT) Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 1F2403A698E for ; Thu, 3 Jul 2008 07:44:52 -0700 (PDT) Received: from [10.31.200.209] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m63EinPc093302; Thu, 3 Jul 2008 10:44:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> Date: Thu, 3 Jul 2008 10:44:45 -0400 To: enum@ietf.org From: Edward Lewis X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Cc: ed.lewis@neustar.biz Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 13:47 +0100 7/3/08, Ray.Bellis@nominet.org.uk wrote: >Peter - following up this comment again: > >> Apologies. NAPTR is becoming the TXT RR for enum; everything can be put >> in there so conveniently, especially using "data" type URIs. That's not >> what NAPTR was designed for. > >I wonder where this concern about NAPTR becoming a dumping ground for data >has come from? (Not speaking for Peter...) For one, the send-n draft. For two a draft I wrote last year. The draft I wrote was presented at the ENUM WG meeting in spring '07 (Prague). I sought to record the E.212 information for a telephone number. After "fleshing it out" and some discussions, it was withdrawn - well, left to expire. It is tempting to define more and more schemes and (ENUM) services. There's no clean set of criteria to judge this, but there's a point at which "one more feature" is "mission creep." The former is desirable, the latter a cancer. >The whole DDDS architecture is *supposed* to be a generic database lookup >system, albeit one that has its origins in ENUM. The only implementation >of DDDS that I'm aware of is RFC3403, and *that* is what specifies NAPTR >records, not the ENUM RFCs. The kinds of mail threads I detest most are ones about what something is "supposed" to be. I can't agree that DDDS is "supposed" to be a generic database, because the DNS upon which it is built is not a database - just a lookup system. I think of it this way - DNS is a piece of infrastructure. It should be quick, reliable, and never noticed by the end user. A database is something more complex. DDDS, ENUM, DNS - all are lookup mechanisms, not database mechanisms. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 08:19:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372323A69C1; Thu, 3 Jul 2008 08:19:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB753A69AE; Thu, 3 Jul 2008 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2BEaY893Hvx; Thu, 3 Jul 2008 08:19:19 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 614C23A6993; Thu, 3 Jul 2008 08:19:19 -0700 (PDT) Received: from beethoven.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 03 Jul 2008 11:19:26 -0400 id 015A4714.486CEDFE.00002725 Message-ID: <486CEDF5.9010800@thinkingcat.com> Date: Thu, 03 Jul 2008 11:19:17 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> In-Reply-To: Cc: enum@ietf.org, enum-bounces@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, Ray.Bellis@nominet.org.uk wrote: > Peter - following up this comment again: > >> Apologies. NAPTR is becoming the TXT RR for enum; everything can be put >> in there so conveniently, especially using "data" type URIs. That's not >> what NAPTR was designed for. > > I wonder where this concern about NAPTR becoming a dumping ground for data > has come from? > > The whole DDDS architecture is *supposed* to be a generic database lookup > system, Yes. > albeit one that has its origins in ENUM. No. Uniform Resource Names. > The only implementation > of DDDS that I'm aware of is RFC3403, and *that* is what specifies NAPTR > records, not the ENUM RFCs. Yes. > > One *could* write a Send-N U-NAPTR Application that sits in its own DNS > tree that happens to represent the structure of some other DNS tree. That > might not be so controversial, but it would *still* be using NAPTR > records. Yes. The interesting question is whether that would (or should) allow differences of use of ENUM (i.e., different dialing plans), which seems to be part of the hearburn here. Leslie. > > As it happens, though, it's actually possible to put the data in the > *same* DNS tree, albeit there are a couple of special edge cases that have > to be taken into consideration. > > Ray > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 08:32:51 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAEA3A6A8C; Thu, 3 Jul 2008 08:32:51 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4138F3A6A8E for ; Thu, 3 Jul 2008 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL0WrCYVcoz2 for ; Thu, 3 Jul 2008 08:32:48 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1FE2C3A6A81 for ; Thu, 3 Jul 2008 08:32:48 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEQne-000224-0d; Thu, 03 Jul 2008 10:32:51 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> Date: Thu, 3 Jul 2008 11:32:16 -0400 Message-ID: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjc7EDx0LqcHlE3QZypDq+DdyAOBQAMaIFA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > Apologies in advance if this comes across as rude, I don't mean it to. > > You've presented this view several times now and on at least a couple of > those occasions a reply has been given explaining why your view is about > something quite different from send-n, except in one edge case. Yet it > doesn't appear that you have addressed that response. So I'm going to > have one more go at explaining this and I would really appreciate you > responding to this rather than restating your view. Actually, my view is you guys are duplicating the PSTN for a subclass of a general problem, and you won't look beyond the copy of the existing solution in a whole new world. Our experience in the IETF is that nearly every time we emulate the PSTN, we come to regret it. When we look at the PROBLEM and then design a good Internet solution to that problem, we are better off. You have a problem: how do you know how long a number is. I think it's a real problem. You have a solution, which is "emulate the PSTN". I think that's a poor solution to a real problem. > > 1. There are a number of different types of ENUM tree out there in use. > They include: > > a) National full number trees, fully populated (or almost) according to a > national numbering plan > b) National user trees, scarcely populated with no algorithmic or other > descriptive means of saying what numbers are in the tree. > c) National number portability trees, partially populated. Again with no > descriptive means of saying what numbers are in the tree. > d) Inter-carrier trees, be definition only partially populated and both > with and without external descriptions of what numbers are in the tree. > e) Lots of other private trees. I agree there are lots of ENUM trees out there, some of which are not complete. > > > 2. The only type of tree from the list above where the type of plan you > are proposing would obviate the need for send-n is a). In all the other > cases, because the tree is not fully populated, only a description of what > numbers are _actually_ in the tree is of any use. This is incorrect. I claim there is never harm in having the information that comes from the regulator, regardless of the completeness of the tree. In the 1% case where there is variability of number length, the variable data need not be complete. I will admit to being concerned about getting the variable data FROM THE AUTHORITATIVE SOURCE. Send-n is indirect; the variable data is obtained from an authoritative source which is then provided to users by the ENUM operator. It's fine with me if the variable data comes from, say, the ENUM operator if someone wants or needs to do that. That may need the protocol to accommodate such arrangements. > > 3. You could of course maintain a separate database for b) and c) with a > list of all numbers in the tree, using something like the protocol you > propose, but I am hoping you are not proposing that because the > duplication of effort, processing overhead and overall complexity would be > astonishing. Nope. The source of the variable data, where it exists, can supply data for only a subset of a full tree. > > 4. I agree totally that we need a the type of protocol that you are > proposing. In fact I think it would be very valuable, more so than > send-n, and I am willing to commit resources to work on it with you if you > wish. Great > > However it is still completely orthogonal to send-n. Why? If you had the data I propose to get, it solves the send-n problem, right? Why would we want two ways to get the same information? This is the crux of the discussion we are having. You think send-n is solving a different problem, rather than a subset of a general problem. I think send-n solves a subset (overlapped dialing) of a general problem, and I want a single solution to the whole problem. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:00:51 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579953A6A92; Thu, 3 Jul 2008 09:00:51 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2062D3A6923 for ; Thu, 3 Jul 2008 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdFbt8sk8yp7 for ; Thu, 3 Jul 2008 09:00:49 -0700 (PDT) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id C6F943A6A92 for ; Thu, 3 Jul 2008 09:00:48 -0700 (PDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KEREt-0004N7-CK for enum@ietf.org; Thu, 03 Jul 2008 17:00:55 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1KEREp-0003T7-Qx for enum@ietf.org; Thu, 03 Jul 2008 17:00:51 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 5B8AD1AB4029 for ; Thu, 3 Jul 2008 17:03:50 +0100 (BST) Message-Id: <1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brains.com> From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Jul 2008 17:00:51 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 3 Jul 2008, at 15:44, Edward Lewis wrote: > The kinds of mail threads I detest most are ones about what > something is "supposed" to be. I can't agree that DDDS is > "supposed" to be a generic database, because the DNS upon which it > is built is not a database - just a lookup system. > > I think of it this way - DNS is a piece of infrastructure. It > should be quick, reliable, and never noticed by the end user. A > database is something more complex. DDDS, ENUM, DNS - all are > lookup mechanisms, not database mechanisms. When I first started playing with NAPTRs on the .tel project I had lots of fun pushing them as far as they could be pushed just to find out what's possible and where they break. Once you start playing they're addictive :) But having explored some particularly deep rabbit-holes I've come to the conclusion that DNS is not the place for any of them. As you say, DNS is infrastructure and it should be quick, reliable and innocuous. The NAPTR extends it elegantly to address unconventional resources (telephones with ENUM, people with .tel, web services, map grid references, whatever) but those resources should always remain separate from the DNS tree itself. What makes send-n interesting is that it's neither a link nor a resource, but introspective meta-data. I can see the logic of a standard NAPTR that links to this data by generating an appropriate URI but using a NAPTR to embody the data itself feels somewhat akin to using an HTTP GET resource to update a database. This is the reason I feel send-n would be better handled via a different RR type specifically geared to tree introspection and validation. I can't comment on whether or not such a generic solution has uses beyond ENUM or how acceptable it will be to the wider DNS community. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:03:17 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BD53A6A91; Thu, 3 Jul 2008 09:03:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504103A6A9C for ; Thu, 3 Jul 2008 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-ahb9Rw2BAw for ; Thu, 3 Jul 2008 09:03:16 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 611F83A6A81 for ; Thu, 3 Jul 2008 09:03:16 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KERHH-0007Cy-SJ; Thu, 03 Jul 2008 18:03:23 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id A7D227742BA; Thu, 3 Jul 2008 18:03:25 +0200 (CEST) Date: Thu, 3 Jul 2008 18:03:25 +0200 From: Peter Koch To: Jay Daley Message-ID: <20080703160325.GC3463@unknown.office.denic.de> Mail-Followup-To: Jay Daley , enum@ietf.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jay, thanks for the summary. Alas, there are some details I disagree with. > 2. The views of some people that overlapped dialling should not be used > cannot be tackled by this draft. It exists, it is used and that is that. Well, yes, but the question remains whether this issue is to be solved within I-ENUM or before I-ENUM-Queries are generated or whether this is an issue at all. > 3. According to all the DNS experts the treatment of wildcards is not an > issue. I'd rephrase that to say that I'd see no protocol issues (... "breaks" ...), but there might remain operational challenges. However, this is closely related to (c) below. > a. Whether or not we need a more general mechanism to describe the shape > of the tree rather than the something just for ENUM? Also expressed as > whether there should be meta-data in the tree about the tree (and whether > NAPTR is a good way to do that)? Likely out of scope for this WG. > and the second two are specifically about send-n: > > c. Is the relative form of send-n worth the trouble? > > d. Is the trade off between extra records vs reduced lookups worth it? Where this includes the question what that trade-off actually is. Also, this isn't just about "extra records", it is also about cluttering the tree. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:20:38 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19263A680D; Thu, 3 Jul 2008 09:20:37 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CE03A680D for ; Thu, 3 Jul 2008 09:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIOtvV8bEKgB for ; Thu, 3 Jul 2008 09:20:36 -0700 (PDT) Received: from smtp3.freeserve.com (smtp3.wanadoo.co.uk [193.252.22.156]) by core3.amsl.com (Postfix) with ESMTP id 3A9AD3A677E for ; Thu, 3 Jul 2008 09:20:36 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3211.me.freeserve.com (SMTP Server) with ESMTP id 168337000085; Thu, 3 Jul 2008 18:20:41 +0200 (CEST) Received: from Codalogic (user-5446fc90.lns6-c13.telh.dsl.pol.co.uk [84.70.252.144]) by mwinf3211.me.freeserve.com (SMTP Server) with SMTP id 3CE197000081; Thu, 3 Jul 2008 18:20:38 +0200 (CEST) X-ME-UUID: 20080703162038249.3CE197000081@mwinf3211.me.freeserve.com Message-ID: <03a101c8dd28$bae96f30$ea00a8c0@Codalogic> From: "Pete Cordell" To: "Brian Rosen" , "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> Date: Thu, 3 Jul 2008 17:20:34 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org - Original Message From: "Brian Rosen" To: "'Jay Daley'" >> However it is still completely orthogonal to send-n. > Why? If you had the data I propose to get, it solves the send-n problem, > right? Why would we want two ways to get the same information? > > This is the crux of the discussion we are having. You think send-n is > solving a different problem, rather than a subset of a general problem. I > think send-n solves a subset (overlapped dialing) of a general problem, > and > I want a single solution to the whole problem. Can you give some more examples of what the "general problem" is? I'm not really getting that from your messages. Also, what do you mean by overlap dialling here? There's obviously the Q.931/SS7 way of doing overlapped sending with INFORMATION messages etc. Or do you use the term in a more abstract sense as in a process of dialling a number without having to press a 'Send' button at the end? To me send-n is a way to iteratively determine the minimum length of an E.164 number. That knowledge does allow you to do overlap dialling (in the sense of dialling without having to press a send button at the end), but it would also allow you answer pub quiz questions along the lines of "what are the minimum number of digits you would have to dial to get a connected call for a number that started +44336?" when no dialling is actually involved. Thanks, Pete Cordell Codalogic _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:21:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBCB3A6AB5; Thu, 3 Jul 2008 09:21:20 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8CE3A6A6D for ; Thu, 3 Jul 2008 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pphKv-jbDAeG for ; Thu, 3 Jul 2008 09:21:18 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 3F7D33A6AB5 for ; Thu, 3 Jul 2008 09:21:01 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KERYS-00032w-Uu; Thu, 03 Jul 2008 18:21:09 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id C3071774325; Thu, 3 Jul 2008 18:21:10 +0200 (CEST) Date: Thu, 3 Jul 2008 18:21:10 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080703162110.GD3463@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Thu, Jul 03, 2008 at 01:47:40PM +0100, Ray.Bellis@nominet.org.uk wrote: > I wonder where this concern about NAPTR becoming a dumping ground for data > has come from? Ed, although not speaking for me, basically hit the nail. "send-n" isn't an ENUM Service, i.e. it isn't anything that you look up to support a communication initiation. Instead, you'd actually look for a "real" service and only use "send-n" in the absence of such, where this NAPTR would conveniently be put into the response, since you asked for this specific, RR type. In turn, the pstndata URI doesn't identify a resource but is a hack to encode arbitrary information in a place where a URI is expected. This fulfills syntax requirements, nothing else. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:27:17 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026E53A69B0; Thu, 3 Jul 2008 09:27:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DB73A677E for ; Thu, 3 Jul 2008 09:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7wpGsXk8SMy for ; Thu, 3 Jul 2008 09:27:14 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id A00503A68DC for ; Thu, 3 Jul 2008 09:27:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Dy5dbO7tMQCQ1ejfWL9tA2Xck4pXZR8GKiy/4lJTDvATcLxZBFh/s+WP E+fz/oxRChrX1sONFrAtqOPYwWKzD3wv+Z8A1LDKNK9Kt88x3KJIpWDEt X0oCFBcxE1pJ4xy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215102443; x=1246638443; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Jay=20Daley"=20|Subject:=20 Re:=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20is sues|Date:=20Thu,=203=20Jul=202008=2017:27:09=20+0100 |Message-ID:=20|To:=20Peter=20Koch=20|Cc:=20enum@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<20080703160325.GC3463@unknown.office.den ic.de>|References:=20=20<20080703160325. GC3463@unknown.office.denic.de>; bh=o4mD3ufSf8wf13BhzWa+MHeA//KUT0BtG6qMlm1Fsjg=; b=qI5xeNPqTmeD145DauIEKl9FnW1NkWUAyT1D/52PgVNKyROhmDeGmNpm PEeMAeO5QlP5IbmZIKiXZyqJYrQeyzQ9ssfnyLK8ZrfNWKwSvyf2ch/WI o1Au5Y9hISZTmj3; X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="4720588" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Jul 2008 17:27:20 +0100 In-Reply-To: <20080703160325.GC3463@unknown.office.denic.de> References: <20080703160325.GC3463@unknown.office.denic.de> To: Peter Koch MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Jay Daley" Date: Thu, 3 Jul 2008 17:27:09 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 05:27:20 PM, Serialize complete at 03/07/2008 05:27:20 PM Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter > > 2. The views of some people that overlapped dialling should not be used > > cannot be tackled by this draft. It exists, it is used and that is that. > > Well, yes, but the question remains whether this issue is to be solved within > I-ENUM or before I-ENUM-Queries are generated or whether this is an issue > at all. You cannot legislate overlap dialling away by protocol design. People have already said they will use it and the implications of that are clear. If you want to say "I would rather we lived with the extra lookups than agree to send-n" then that is fine - it is basically an answer to d) below. BTW this is all ENUM not just I-ENUM. > > 3. According to all the DNS experts the treatment of wildcards is not an > > issue. > > I'd rephrase that to say that I'd see no protocol issues (... "breaks" ...), > but there might remain operational challenges. However, this is closely > related to (c) below. Fine by me. > > a. Whether or not we need a more general mechanism to describe the shape > > of the tree rather than the something just for ENUM? Also expressed as > > whether there should be meta-data in the tree about the tree (and whether > > NAPTR is a good way to do that)? > > Likely out of scope for this WG. I agree entirely it would be if that is the way the answer went. But we first need to agree whether to go this way or something more specific like send-n or whether to do nothing. > > d. Is the trade off between extra records vs reduced lookups worth it? > > Where this includes the question what that trade-off actually is. Also, > this isn't just about "extra records", it is also about cluttering the tree. I meant that as well in the phrase "extra records". There are lots of reasons people might not want the extra records. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:36:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7483A6CFC; Thu, 3 Jul 2008 09:36:22 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983DD3A6CF2 for ; Thu, 3 Jul 2008 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGHaTTKB8f8X for ; Thu, 3 Jul 2008 09:36:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 7A1F03A6D09 for ; Thu, 3 Jul 2008 09:31:40 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so330707fga.41 for ; Thu, 03 Jul 2008 09:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=rWD0lcm8q1XsgxlE/+VbxuZ8DCb6kGvsnJCIQR3gNko=; b=jSGH4EN+jHkqox0PH6VbvI+34zZtzzfDR9SF6ofSAOvVl4RhIewKDccHqZEuCRaTOE jeq5xtVJ3yVIq1uL2xKNrqtNO0ORSMZIDJfbFXSyGttD4nB59dJDKmSwMyCFAfhpVfEc Y5nWwmzMmmON+lqh7l4BpmlYHK2CCuagWuDDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=kxOcLoxWIGd3uUiCZrJO0/dCVuPRqwahXIBqBO6MQVBS2wMoWa2vPp43As7lc5VQsj 3SE3EQtKYUQe6/mK3Su+XQh8zKglFawrQO/rgeLRVFPniUlafa9IxG6rj1TR0lRMO+GF e9YN8IcHuQBrQwzWEoGOp8XJNiz9pMErkN4UQ= Received: by 10.86.31.18 with SMTP id e18mr192565fge.34.1215102708442; Thu, 03 Jul 2008 09:31:48 -0700 (PDT) Received: by 10.86.1.16 with HTTP; Thu, 3 Jul 2008 09:31:48 -0700 (PDT) Message-ID: <72b755bf0807030931q6eabf9e6vf02fcb269b7bd036@mail.gmail.com> Date: Thu, 3 Jul 2008 12:31:48 -0400 From: "Richard Shockey" To: enum@ietf.org MIME-Version: 1.0 Subject: [Enum] WG last call on IANA registration IAX X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2015063762==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============2015063762== Content-Type: multipart/alternative; boundary="----=_Part_8177_4792185.1215102708426" ------=_Part_8177_4792185.1215102708426 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Title : IANA Registration for IAX Enumservice Author(s) : E. Guy Filename : draft-ietf-enum-iax-04.txt Pages : 9 Date : 2008-06-17 This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-04.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today June 17 2008 until though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 > > ------=_Part_8177_4792185.1215102708426 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Title                 : IANA Registration for IAX Enumservice

      Author(s)       : E. Guy

      Filename        : draft-ietf-enum-iax-04.txt

      Pages           : 9

      Date            : 2008-06-17

 

This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-04.txt

     

The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard.

 

The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction.

 

Work group last call will extend for 2 weeks or so from today June 17 2008 until though we can modify that if new issues come up.

 

 

Richard Shockey

Director, Member of the Technical Staff

NeuStar

46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 <mailto:richard(at)shockey.us> <mailto:richard.shockey(at)neustar.biz>

 

 

------=_Part_8177_4792185.1215102708426-- --===============2015063762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --===============2015063762==-- From enum-bounces@ietf.org Thu Jul 3 09:58:21 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E163A6C45; Thu, 3 Jul 2008 09:58:21 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90743A6C9D for ; Thu, 3 Jul 2008 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOGRyWP-jZgS for ; Thu, 3 Jul 2008 09:58:18 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id C69663A6C45 for ; Thu, 3 Jul 2008 09:58:18 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KES8X-0001zJ-Vv; Thu, 03 Jul 2008 18:58:26 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id CBBD477447F; Thu, 3 Jul 2008 18:58:27 +0200 (CEST) Date: Thu, 3 Jul 2008 18:58:27 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080703165827.GE3463@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <72b755bf0807030931q6eabf9e6vf02fcb269b7bd036@mail.gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <72b755bf0807030931q6eabf9e6vf02fcb269b7bd036@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] WG last call on IANA registration IAX X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Thu, Jul 03, 2008 at 12:31:48PM -0400, Richard Shockey wrote: > http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-04.txt > The intent of the last call is to solicit comments before submitting the ID > to the IESG as a Proposed Standard. This draft has a normative reference to draft-guy-iax-04, which is in the RFC editor queue waiting for publication as an Informational RFC. Since the normative reference is correct, how is the downref going to be handled? Wouldn't this be a good candidate for a preliminary processing under the "ENUM service guidelines" document? NIT: The NAPTR RRs should use the '(' ')' syntax instead of '\' as a line end escape (RFC 1035, section 5.1), i.e.: $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. @ IN NAPTR ( 10 100 "u" "E2U+iax:iax" "!^.*$!iax:example.com/chas!" . ) -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 09:58:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A553A6A11; Thu, 3 Jul 2008 09:58:58 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFF63A69C6 for ; Thu, 3 Jul 2008 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrUyQnQG2xCb for ; Thu, 3 Jul 2008 09:58:56 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 8B4523A69A7 for ; Thu, 3 Jul 2008 09:58:20 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m5UMkTgJ026779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jun 2008 15:46:51 -0700 From: "Richard Shockey" To: "'Duane'" , "'Clive D.W. Feather'" References: <124501c8d60c$4a73bdf0$bf320446@cis.neustar.com> <20080627124511.GD99368@finch-staff-1.thus.net> <171b01c8d85e$a5d4a0c0$bf320446@cis.neustar.com> <4DCA5128-C6F5-4F27-8570-AC00C9867333@insensate.co.uk> <20080630151703.GV45239@finch-staff-1.thus.net> <48695A5D.5020308@e164.org> In-Reply-To: <48695A5D.5020308@e164.org> Date: Mon, 30 Jun 2008 18:47:12 -0400 Message-ID: <034101c8db03$6531da90$2f958fb0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acja/mkbi4stTWnRQHaBpnkYHveJwQABMYqg Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, 'Lawrence Conroy' Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > Clive D.W. Feather wrote: > > > It's also an issue of how to get dial plan information out to > everyone who > > might possibly need it. That needs to be a pull system, not a push > one, > > since there will be far too many potential users to keep a master > list; we > > don't even know who all those users might be. It needs to allow for > > delegated databases rather than requiring a single authoritative > source who > > has to update everything, since we don't know how often updates will > happen > > (often in Austria, I believe). It ought to allow for cacheing. And > it ought > > not to require everything to be downloaded again just because one > leaf of > > the tree has changed. > > > > Remind you of anything? > > Yup, BGP Yea and we all know where TRIP went ... > > -- > > Best regards, > Duane > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 10:15:42 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6373A69BA; Thu, 3 Jul 2008 10:15:42 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F1D3A699E for ; Thu, 3 Jul 2008 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NCwPBzaJFJC for ; Thu, 3 Jul 2008 10:15:40 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id D5A5E3A69BA for ; Thu, 3 Jul 2008 10:15:29 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m63HBp98006781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2008 10:12:07 -0700 From: "Richard Shockey" To: "'Peter Koch'" , "'IETF ENUM WG'" References: <72b755bf0807030931q6eabf9e6vf02fcb269b7bd036@mail.gmail.com> <20080703165827.GE3463@unknown.office.denic.de> In-Reply-To: <20080703165827.GE3463@unknown.office.denic.de> Date: Thu, 3 Jul 2008 13:12:31 -0400 Message-ID: <00ba01c8dd30$13261250$397236f0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjdLfHLF2YBcR3fQzu+rRITpqG69AAAd9XQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] WG last call on IANA registration IAX X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Peter Koch > Sent: Thursday, July 03, 2008 12:58 PM > To: IETF ENUM WG > Subject: Re: [Enum] WG last call on IANA registration IAX > > On Thu, Jul 03, 2008 at 12:31:48PM -0400, Richard Shockey wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-04.txt > > > The intent of the last call is to solicit comments before submitting > the ID > > to the IESG as a Proposed Standard. > > This draft has a normative reference to draft-guy-iax-04, which is in > the > RFC editor queue > waiting for publication as an Informational RFC. > > Since the normative reference is correct, how is the downref going > to be handled? Good question .. > Wouldn't this be a good candidate for a preliminary processing under > the > "ENUM service guidelines" document? Sure ..but are we sufficiently ready to go to last call after Dublin?? > > NIT: The NAPTR RRs should use the '(' ')' syntax instead of '\' as > a line end escape (RFC 1035, section 5.1), i.e.: > > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > > @ IN NAPTR ( 10 100 "u" "E2U+iax:iax" > "!^.*$!iax:example.com/chas!" . ) > > -Peter > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 10:18:40 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5578F3A699E; Thu, 3 Jul 2008 10:18:40 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA613A6833; Thu, 3 Jul 2008 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTrAQn-k8JVk; Thu, 3 Jul 2008 10:18:38 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 0D0283A69A7; Thu, 3 Jul 2008 10:18:37 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m63HFu5H011702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2008 10:16:12 -0700 From: "Richard Shockey" To: "'IETF ENUM WG'" , , Date: Thu, 3 Jul 2008 13:16:36 -0400 Message-ID: <00bb01c8dd30$9f21cba0$dd6562e0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjdMIwsKUuNx9DXQEujyZptauCWzQ== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] REMINDER ... Internet DRAFT cut off dates... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org July 7, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 10:29:01 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB673A6928; Thu, 3 Jul 2008 10:29:01 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CF53A67BD for ; Thu, 3 Jul 2008 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53CsRjiEzw7h for ; Thu, 3 Jul 2008 10:28:59 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id C37073A693C for ; Thu, 3 Jul 2008 10:28:58 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m63HMqPO015648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Jul 2008 10:23:08 -0700 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Thu, 3 Jul 2008 13:23:32 -0400 Message-ID: <00bd01c8dd31$97198ff0$c54cafd0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjdMYRA2F2u/USgQ8alh9vAfo+hoA== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] FIRST CUT at ENUM aganda.. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org What am I missing? ***************** IETF 72 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 10 2. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-10.txt Pages : 40 Date : 2008-05-19 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-10.tx t Title : Update of legacy IANA Registrations of Enumservices Author(s) : B. Hoeneisen, A. Mayrhofer Filename : draft-hoeneisen-enum-enumservices-transition-01.txt Pages : 21 Date : 2008-05-20 This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-enumservices-transi tion-01.txt Title : IANA Registration of Experimental and Trial Enumservices (X-Enumservices) Author(s) : B. Hoeneisen Filename : draft-ietf-enum-x-service-regs-01.txt Pages : 15 Date : 2008-05-21 This document specifies a new IANA registry for experimental and trial Enumservices (X-Enumservices), describes corresponding registration procedures, and provides a guideline for creating X-Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-x-service-regs-01.txt 3. Title : IANA Registrations for the 'Send-N' Enumservice Author(s) : R. Bellis Filename : draft-bellis-enum-send-n-02.txt Pages : 11 Date : 2008-06-23 This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-02.txt 4. New UNUSED ?????? Hadriel 5. New SOURCE URI ?? Hadriel 6. Title : IANA Registration for an Enumservice Subtype "smpp" under Type "sms", and Information and IANA Registration for URI Type "smpp" Author(s) : J. Yu Filename : draft-yu-enumservice-sms-smpp-01.txt Pages : 12 Date : 2008-4-14 This document updates RFC 4355 by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 and draft-ietf-enum-enumservices-guide-07 and registers a new URI type "smpp" according to the URI registration procedure in RFC 4395. This enumservice subtype indicates that the remote resource identified by the URI scheme can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP). 7. Title : IANA Registration for Location ('loc') Enumservice Author(s) : A. Mayrhofer Filename : draft-mayrhofer-enum-loc-enumservice-00.txt Pages : 9 Date : 2008-06-19 This document requests IANA registration of an Enumservice for reflecting location information. The Enumservice uses the 'loc' Type name, and makes use of the proposed 'held' and 'geo' URI schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-loc-enumservice-00. txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 11:07:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322433A6CD4; Thu, 3 Jul 2008 11:07:31 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB513A6C45 for ; Thu, 3 Jul 2008 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8w57+vWwBVB for ; Thu, 3 Jul 2008 11:07:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 178E23A6768 for ; Thu, 3 Jul 2008 11:07:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KETDN-0001rp-Oq; Thu, 03 Jul 2008 13:07:30 -0500 From: "Brian Rosen" To: "'Pete Cordell'" , "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03a101c8dd28$bae96f30$ea00a8c0@Codalogic> Date: Thu, 3 Jul 2008 14:07:31 -0400 Message-ID: <038101c8dd37$ad067340$e76af444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <03a101c8dd28$bae96f30$ea00a8c0@Codalogic> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjdKLxwD1a/qab6Qb+wUe8VG6VzzgADbD8g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Please read the thread. The general problem is determining the length of a number. The subset is the problem of overlapped dialing where the endpoint is sending digits blindly and the network doesn't know what the length of the number is. Other examples I have given include: 1. Validating the shape of an ENUM tree by the ENUM operator. 2. Intelligent end devices with SEND buttons and clever GUIs that react well 3. Proxy servers and other systems validating numbers before attempting to route 4. Routing and rating systems diagnosing problems The general problem of determining the length of a TN is a good problem. I think we should solve it. Solving overlapped dialing by emulating how the PSTN does it is, in my opinion, a poor choice of solution. And, echoing Peter Koch, enum may not be the appropriate work group to solve the problem. Brian > -----Original Message----- > From: Pete Cordell [mailto:peteietf@codalogic.com] > Sent: Thursday, July 03, 2008 12:21 PM > To: Brian Rosen; 'Jay Daley' > Cc: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > - Original Message From: "Brian Rosen" > To: "'Jay Daley'" > >> However it is still completely orthogonal to send-n. > > Why? If you had the data I propose to get, it solves the send-n > problem, > > right? Why would we want two ways to get the same information? > > > > This is the crux of the discussion we are having. You think send-n is > > solving a different problem, rather than a subset of a general problem. > I > > think send-n solves a subset (overlapped dialing) of a general problem, > > and > > I want a single solution to the whole problem. > > Can you give some more examples of what the "general problem" is? I'm not > really getting that from your messages. > > Also, what do you mean by overlap dialling here? There's obviously the > Q.931/SS7 way of doing overlapped sending with INFORMATION messages etc. > Or > do you use the term in a more abstract sense as in a process of dialling a > number without having to press a 'Send' button at the end? > > To me send-n is a way to iteratively determine the minimum length of an > E.164 number. That knowledge does allow you to do overlap dialling (in > the > sense of dialling without having to press a send button at the end), but > it > would also allow you answer pub quiz questions along the lines of "what > are > the minimum number of digits you would have to dial to get a connected > call > for a number that started +44336?" when no dialling is actually involved. > > Thanks, > > Pete Cordell > Codalogic _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 12:41:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17933A6903; Thu, 3 Jul 2008 12:41:52 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60ED03A67EF for ; Thu, 3 Jul 2008 12:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qZTxNhQfbFr for ; Thu, 3 Jul 2008 12:41:50 -0700 (PDT) Received: from smtp2.freeserve.com (smtp2.wanadoo.co.uk [193.252.22.157]) by core3.amsl.com (Postfix) with ESMTP id 3D1413A680E for ; Thu, 3 Jul 2008 12:41:48 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3111.me.freeserve.com (SMTP Server) with ESMTP id 9A18F7000083; Thu, 3 Jul 2008 21:41:48 +0200 (CEST) Received: from Codalogic (user-5446fc90.lns6-c13.telh.dsl.pol.co.uk [84.70.252.144]) by mwinf3111.me.freeserve.com (SMTP Server) with SMTP id 9F1EF7000081; Thu, 3 Jul 2008 21:41:47 +0200 (CEST) X-ME-UUID: 20080703194147651.9F1EF7000081@mwinf3111.me.freeserve.com Message-ID: <001401c8dd44$d4cf9e30$ea00a8c0@Codalogic> From: "Pete Cordell" To: "Brian Rosen" , "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03a101c8dd28$bae96f30$ea00a8c0@Codalogic> <038101c8dd37$ad067340$e76af444@cis.neustar.com> Date: Thu, 3 Jul 2008 20:41:38 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org - Original Message From: "Brian Rosen" > Please read the thread. I have been. I might have missed stuff though. > The general problem is determining the length of a > number. The subset is the problem of overlapped dialing where the > endpoint > is sending digits blindly and the network doesn't know what the length of > the number is. Doesn't a regular SIP UA have the same issue - knowing when it's got sufficient digits to get a final URI? Send-n can work in that case also. Surely it's not all about carriers? > Other examples I have given include: > 1. Validating the shape of an ENUM tree by the ENUM operator. How does your web service proposal improve on this? Presumably this is mainly a problem when an ENUM operator delegates a number range to a customer. Is it the ENUM operators responsibility to monitor that tree any more than it is ICANN's (or is it Versign or someone) responsibility to monitor the shape of the .com tree? > 2. Intelligent end devices with SEND buttons and clever GUIs that react > well Since such devices are relying on a user to tell them the length of a number I don't see that this needs solving. > 3. Proxy servers and other systems validating numbers before attempting to > route Why can't Send-n do this? Surely you just do the relevant DNS query? > 4. Routing and rating systems diagnosing problems How does the web service solution improve this? > The general problem of determining the length of a TN is a good problem. > I > think we should solve it. Solving overlapped dialing by emulating how the > PSTN does it is, in my opinion, a poor choice of solution. I'm just not seeing how your web service proposal offers anything that Send-n doesn't. They both allow you to find out how many digits you have to dial to get an end device. > And, echoing Peter Koch, enum may not be the appropriate work group to > solve > the problem. That may be. I'm coming from a position of a UK user that doesn't want their (or their mum's) dialling experience to suffer when the future finally arrives. My perception is that many in the US and other parts of the world don't consider variable length numbers an issue, and it's gnarly details shouldn't contaminate their beautiful technology. We also have to bear in mind that mobile phones are no longer (well, probably never have been) the smallest devices to connect to the internet. Why should your fridge download a megabyte table just to be able to tell you it needs defrosting. There are also very small IP enabled ZigBee devices that we shouldn't prevent from using ENUM. On that note, we shouldn't assume that such devices are always on either. I turn off my PCs at night to do my bit to help save the planet. (I hope everyone reading this does also!) To me that suggests that a push update system is not appropriate. I personally wouldn't care whether the whole solution is turned over to a web service type solution as long as satisfactory user experience was there. I find it difficult to think that a system that starts out doing web service queries, and then switches over to doing DNS queries is sensible. It should be all web service, or all DNS. Not only does that seem aesthetically more pleasing to me, I would have thought it would make it easier to maintain coherency of the data. Thanks, Pete. -- ============================================= Pete Cordell Codalogic ============================================= _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 13:19:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D3A3A6915; Thu, 3 Jul 2008 13:19:45 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DD63A6915; Thu, 3 Jul 2008 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlCu28vnAuCn; Thu, 3 Jul 2008 13:19:42 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 6E13E3A67E2; Thu, 3 Jul 2008 13:19:41 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=OqG8LXDn8GnSRrKOhigwYB44MhkUo0AcVzqkGZPXHduQ67p9wLyWN1BZ BA2e+15HejQCGXlYlS3GHXcEi8yGx5jP4IWkj8wB6+rMzyL8SNWbXs/hY /K+G1Q9Ldo2atZf; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215116391; x=1246652391; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Re :=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20issu es|Date:=20Thu,=203=20Jul=202008=2021:19:48=20+0100 |Message-ID:=20|To:=20"Brian=20Rosen"=20 |Cc:=20enum@ietf.org,=0D=0A=09enum-bou nces@ietf.org|MIME-Version:=201.0|In-Reply-To:=20<02dc01c 8dd22$0e684480$e76af444@cis.neustar.com>|References:=20=0D=0A=09<018901c8dcb3$9f3f1f70$e76af444@c is.neustar.com>=09=20<02dc01c8dd22$0e684 480$e76af444@cis.neustar.com>; bh=58EMUOiMHs/Abv6bSLLcZYCh67rG+Ah1Um7NE0EskWk=; b=id1dw91Ed89zDG5+Fvf2noxdJyJCq25xXcttvTH1D1cUShbAt9u3G0VW rLDsqUblI5kF9UzZY+cDMIvfp1ueOUxnvB54BnmIj9Cm96otXDqT5upCl 5OSLflCI2hiNyZ0; X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="3886192" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2008 21:19:49 +0100 In-Reply-To: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Thu, 3 Jul 2008 21:19:48 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 09:19:49 PM, Serialize complete at 03/07/2008 09:19:49 PM Cc: enum@ietf.org, enum-bounces@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian > > However it is still completely orthogonal to send-n. > Why? If you had the data I propose to get, it solves the send-n problem, > right? Why would we want two ways to get the same information? It only solves the send-n problem if: * every device that is going to do the ENUM lookup is pre-loaded with every data document for every country that might be dialled. * the tree being queried is sufficiently densely populated so that the number of times there is no number found (despite being in the number plan) is minimised. send-n on the other hand: * does not require any device to be loaded with any document * does not require the tree to be filled in any way Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 13:28:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC25C3A6915; Thu, 3 Jul 2008 13:28:22 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BAA73A6915 for ; Thu, 3 Jul 2008 13:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9efLbynn58Jl for ; Thu, 3 Jul 2008 13:28:21 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 56A4F3A67E2 for ; Thu, 3 Jul 2008 13:28:20 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=7MtiahtTe7wTZe8+cig7aZ5ZfV4jWW7aOSZOCOWABTSn23Vc48pXiIEq a/KfsRJw3qcA6X9437RGY7svDA+EBSo+H59oEIVHWWcMENdtaIMcq2tky kaeaShxVYUxSi+P; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215116910; x=1246652910; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Re :=20[Enum]=20Send-N=20draft:=20draft-bellis-enum-send-n-0 2=20published|Date:=20Thu,=203=20Jul=202008=2021:28:26=20 +0100|Message-ID:=20|To:=20Eleanor=20McH ugh=20|Cc:=20IETF=20ENUM =20WG=20|MIME-Version:=201.0|In-Reply-To: =20<1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brain s.com>|References:=20<48657FC5.2010205@e164.org>=09=0D=0A=09<20080629132325.GA23998@x27.adm.denic .de>=09=0D=0A=09<20080630160805.GK487@un known.office.denic.de>=09=0D=0A=09=20<1775503D-350B-4F65-B D46-36BD97BDC320@games-with-brains.com>; bh=D93GDisXe1lfjbnbCwFAP+ERsyTeXNcLD0Ug1eCLQlk=; b=MfnlSUFLZViziFuWtrgVX7SpCZiQnBP9vkfbZ0GfBNEFAi7g/lwatRxr J3fs9wzx6Fqv+kaB8XIeNyptBAmtvg7gOPaUnlywX72yZcvM70RZeU6gh T0CQZ0aENi3bIyh; X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="3886293" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Jul 2008 21:28:28 +0100 In-Reply-To: <1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brains.com> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brains.com> To: Eleanor McHugh MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Thu, 3 Jul 2008 21:28:26 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/07/2008 09:28:28 PM, Serialize complete at 03/07/2008 09:28:28 PM Cc: IETF ENUM WG Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ellie > What makes send-n interesting is that it's neither a link nor a > resource, but introspective meta-data. I can see the logic of a > standard NAPTR that links to this data by generating an appropriate > URI but using a NAPTR to embody the data itself feels somewhat akin to > using an HTTP GET resource to update a database. This is the reason I > feel send-n would be better handled via a different RR type > specifically geared to tree introspection and validation. > > I can't comment on whether or not such a generic solution has uses > beyond ENUM or how acceptable it will be to the wider DNS community. I can see the attraction but this is more a thought experiment than a practical solution. This is because * it has no use case; * the security implications are too great of one label being able to make statements about lower labels that might be under different admin control. If you think it is a good idea then please suggest it to dnsext, but I suspect it will not get much traction. Hence my view that send-n is best as it is, a limited solution for ENUM. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 16:32:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF93C3A6AF2; Thu, 3 Jul 2008 16:32:01 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782143A6AF8 for ; Thu, 3 Jul 2008 16:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNrbJR34hUyh for ; Thu, 3 Jul 2008 16:31:59 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 40BA43A6AFA for ; Thu, 3 Jul 2008 16:31:45 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 17083A584E; Fri, 4 Jul 2008 00:31:53 +0100 (BST) Message-Id: <79147992-6216-42E6-86E0-202CC85A2B0E@insensate.co.uk> From: Lawrence Conroy To: Richard Shockey In-Reply-To: <00ba01c8dd30$13261250$397236f0$@us> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 4 Jul 2008 00:31:52 +0100 References: <72b755bf0807030931q6eabf9e6vf02fcb269b7bd036@mail.gmail.com> <20080703165827.GE3463@unknown.office.denic.de> <00ba01c8dd30$13261250$397236f0$@us> X-Mailer: Apple Mail (2.926) Cc: 'IETF ENUM WG' , 'Peter Koch' Subject: Re: [Enum] WG last call on IANA registration IAX X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, folks Peter wrote: >> Since the normative reference is correct, how is the downref going >> to be handled? On 3 Jul 2008, at 18:12, Richard Shockey responded: > Good question .. The current situation in which an Enumservice has to be on the Standards Track seems unduly rigid in this case, as the IAX protocol (and thus the URI scheme) is always going to be Informational. There is a spec to cover IAX and thus to specify the URI scheme. The protocol has been in use for ages. Peter also wrote: >> Wouldn't this be a good candidate for a preliminary processing >> under the "ENUM service guidelines" document? To which Richard replied: > Sure ..but are we sufficiently ready to go to last call after Dublin?? Pullleeeeese - make the pain stop. If the new Enumservice registration guide and process is not ready to approve now, it never will be. I haven't seen anyone come up with a problem with the guide. I'm not even sure that we need to wait for the end of the (Outside) Dublin meeting to start the WGLC. It will wait in the RFC Editor queue anyway, as it has a normative reference to 3761bis (no surprise there :). Even starting the WGLC on the guide now, how long d'you reckon it will be before ANY Enumservice can go through the new process and make it onto the IANA Enumservice registry? The IAX Enumservice is useful, is correct, and to block it because it uses a URI scheme with an Informational Specification is not reasonable. It is even more cruel and unusual punishment to to make it wait some time until the WG is done with the guide, then the IETF is done, then the IESG approves the guide, then the RFC Editor does his/her stuff, then IANA gets the Enumservice Registry process ready, then the IESG selects an expert, then Ed Guy has to go through the process again by submitting it to the ENUM list, waiting for feedback, then sending it and the template to IANA, then IANA has to pass this to the expert, then that expert has to approve the request, then IANA has to process this report and has to update the registry. All because it has a necessary and reasonable downref to the (obviously) Informational IAX protocol and URI scheme? C'mon. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 16:34:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F223A6B03; Thu, 3 Jul 2008 16:34:57 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765AC3A6AEE for ; Thu, 3 Jul 2008 16:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKkvxOJj4+tE for ; Thu, 3 Jul 2008 16:34:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 023BD3A6A40 for ; Thu, 3 Jul 2008 16:34:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEYK7-0008V0-3E; Thu, 03 Jul 2008 18:34:52 -0500 From: "Brian Rosen" To: "'Pete Cordell'" , "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03a101c8dd28$bae96f30$ea00a8c0@Codalogic> <038101c8dd37$ad067340$e76af444@cis.neustar.com> <001401c8dd44$d4cf9e30$ea00a8c0@Codalogic> Date: Thu, 3 Jul 2008 19:34:22 -0400 Message-ID: <03df01c8dd65$67d84040$e76af444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001401c8dd44$d4cf9e30$ea00a8c0@Codalogic> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjdRNKMUZKr+vtyRgWFRSSj8b4sDAAGmncw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Doesn't a regular SIP UA have the same issue - knowing when it's got > sufficient digits to get a final URI? Send-n can work in that case also. > Surely it's not all about carriers? No, Send-N cannot work in those cases. First of all, that would mean that the UA is doing repeated ENUM dips, and except in the case of User ENUM (which doesn't seem to have much traction), is not possible. It's also, for intelligent SIP UAs the wrong mechanism because they use something akin to an MGCP digit map to interpret user GUI interactions. Think of a device which knows when it has enough digits that behaves as if it had a SEND button, but actually the call is automatically placed when the terminal digit is dialed. Regardless, the UA wants to have the dialing plan, not send-n. > > > Other examples I have given include: > > 1. Validating the shape of an ENUM tree by the ENUM operator. > > How does your web service proposal improve on this? > > Presumably this is mainly a problem when an ENUM operator delegates a > number > range to a customer. Is it the ENUM operators responsibility to monitor > that tree any more than it is ICANN's (or is it Versign or someone) > responsibility to monitor the shape of the .com tree? No. As an example, the ENUM operator would wish to validate that a number is a good number before allowing provisioning on the number. I can speak from some level of experience here, and having good number length data is very useful when you are operating an ENUM database. > > > 2. Intelligent end devices with SEND buttons and clever GUIs that react > > well > > Since such devices are relying on a user to tell them the length of a > number > I don't see that this needs solving. I think this is incorrect. You are repeating the current mobile experience, where it is entirely the user's responsibility to know when enough digits have been dialed, and the system's only response is an error tone or announcement which, typically, is not helpful. If the device knows that the number so far entered is not yet complete, it can alert the user of that fact, either before or after SEND is pressed. > > > 3. Proxy servers and other systems validating numbers before attempting > to > > route > > Why can't Send-n do this? Surely you just do the relevant DNS query? Because the entity with ENUM access is typically not the entity doing the validation. Typically, the ENUM query is at a border element, whereas the validation function is closer to the user. > > > 4. Routing and rating systems diagnosing problems > > How does the web service solution improve this? Because the mechanism tells you how long a number is. It tells you what good numbers look like. It gives you the whole picture. If you have a number, and it fails to route, you can easily determine what is wrong if the problem is too many or too few digits. Send-N couldn't do that, at least easily. > > > The general problem of determining the length of a TN is a good problem. > > I > > think we should solve it. Solving overlapped dialing by emulating how > the > > PSTN does it is, in my opinion, a poor choice of solution. > > I'm just not seeing how your web service proposal offers anything that > Send-n doesn't. They both allow you to find out how many digits you have > to > dial to get an end device. In the end, you can, by doing enough queries, determine the shape of the tree, so yes, send-n can be used for everything but validating the enum database shape (which is a chicken and egg problem for send-n). On the other hand, it's pretty darn inefficient to figure out a dialing plan by doing a bunch of enum queries to get the shape of the number plan. Think about how you would go about creating an MGCP style digit map using send-n. > > > And, echoing Peter Koch, enum may not be the appropriate work group to > > solve > > the problem. > > That may be. > > I'm coming from a position of a UK user that doesn't want their (or their > mum's) dialling experience to suffer when the future finally arrives. My > perception is that many in the US and other parts of the world don't > consider variable length numbers an issue, and it's gnarly details > shouldn't > contaminate their beautiful technology. On the contrary, no one is arguing that we shouldn't have a solution that allows overlapped dialing using black phones but ENUM routing to work. What I'm saying is that it should be possible to improve user experiences with newer devices, and other parts of the solution space need number length data. > > We also have to bear in mind that mobile phones are no longer (well, > probably never have been) the smallest devices to connect to the internet. > Why should your fridge download a megabyte table just to be able to tell > you > it needs defrosting. There are also very small IP enabled ZigBee devices > that we shouldn't prevent from using ENUM. Then keep the data at the proxy and let the user device do something simpler. The end device doesn't do ENUM, although I agree we don't prohibit that and shouldn't. Since it seems to be a fact that they don't, perhaps a different solution is better. > > On that note, we shouldn't assume that such devices are always on either. > I > turn off my PCs at night to do my bit to help save the planet. (I hope > everyone reading this does also!) To me that suggests that a push update > system is not appropriate. Not sure who is promoting push update. > > I personally wouldn't care whether the whole solution is turned over to a > web service type solution as long as satisfactory user experience was > there. > I find it difficult to think that a system that starts out doing web > service > queries, and then switches over to doing DNS queries is sensible. It > should > be all web service, or all DNS. Not only does that seem aesthetically > more > pleasing to me, I would have thought it would make it easier to maintain > coherency of the data. Well, I suppose it's the notion that if we are talking about an intelligent device, first they do some kind of digit map thing, then they do some kind of routing thing. They aren't the same thing. ENUM is a routing database. This isn't a routing problem. It's actually a UI problem, at least the part you are working on. Brian _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 17:00:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF923A6A40; Thu, 3 Jul 2008 17:00:57 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23173A6AEE; Thu, 3 Jul 2008 17:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIZMwikREUdg; Thu, 3 Jul 2008 17:00:55 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id EE02B3A6A40; Thu, 3 Jul 2008 17:00:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEYjM-0001WA-EX; Thu, 03 Jul 2008 19:00:53 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> Date: Thu, 3 Jul 2008 20:00:57 -0400 Message-ID: <03e001c8dd69$0b950800$e76af444@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjdSiIhRYb337hpTzKnbsNkM38+YQAGzN6A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org, enum-bounces@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > It only solves the send-n problem if: > > * every device that is going to do the ENUM lookup is pre-loaded with > every data document for every country that might be dialled. > * the tree being queried is sufficiently densely populated so that the > number of times there is no number found (despite being in the number > plan) is minimised. Nah, I don't think you will preload everything, just cache what you use the most. Download whatever else you need on demand. The data I'm proposing gives you validation of number length. It doesn't tell you that you have a working number. It gives you the information you need to invoke routing. In many systems, you won't get information on whether a given service is available on a given number until you actually try to invoke the service. I'm not too thrilled with that, but it's the way things work in some cases now. If we fixed that, then the actual ENUM query would get you that information. However, as I said, in general, the device in the network that has ENUM access is at the border of the network and the device that handles something like dial plan interpretation is near the user, so you would have to have some other mechanism to propagate the information back towards the proxy server doing the dial plan interpretation, or have more systems with ENUM access. The latter has its own operational issues. That kind of thing is solvable, but it's an indication to me that the solution has not yet been thought all the way through. Brian _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 3 18:08:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDEC3A688B; Thu, 3 Jul 2008 18:08:16 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C113A688B for ; Thu, 3 Jul 2008 18:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S16LkctUWy9W for ; Thu, 3 Jul 2008 18:08:13 -0700 (PDT) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 5C5553A6886 for ; Thu, 3 Jul 2008 18:08:13 -0700 (PDT) Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KEZmf-0005aO-G9 for enum@ietf.org; Fri, 04 Jul 2008 02:08:21 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52) id 1KEZmf-0000R4-0z for enum@ietf.org; Fri, 04 Jul 2008 02:08:21 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 5BBE41AC36BB for ; Fri, 4 Jul 2008 02:11:20 +0100 (BST) Message-Id: <8D9E8C74-51BF-412A-A934-350E61D15F7B@games-with-brains.com> From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Jul 2008 02:08:20 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brains.com> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 3 Jul 2008, at 21:28, Jay Daley wrote: > Ellie >> What makes send-n interesting is that it's neither a link nor a >> resource, but introspective meta-data. I can see the logic of a >> standard NAPTR that links to this data by generating an appropriate >> URI but using a NAPTR to embody the data itself feels somewhat akin >> to >> using an HTTP GET resource to update a database. This is the reason I >> feel send-n would be better handled via a different RR type >> specifically geared to tree introspection and validation. >> >> I can't comment on whether or not such a generic solution has uses >> beyond ENUM or how acceptable it will be to the wider DNS community. > > I can see the attraction but this is more a thought experiment than a > practical solution. Agreed. But it's a thought experiment that could have practical value as it hints at there being more to the send-n problem than just hinting at the number of valid digits in an ENUM lookup. > This is because > > * it has no use case; Well I can see benefits to it: a. it solves the number length problem in ENUM b. it allows the shape of portions of the DNS tree to be specified and validated c. it could be used to enforce naming policies and I'm certain that someone more knowledgeable in general DNS usage could build use cases which exploit these. > * the security implications are too great of one label being able to > make > statements about lower labels that might be under different admin > control. I've missed something in my interpretation of the send-n draft as I don't see how using a non-NAPTR resource to achieve the same effect makes any difference. In both cases the RR is making statements about the shape of the tree beneath the current level. > If you think it is a good idea then please suggest it to dnsext, but I > suspect it will not get much traction. Hence my view that send-n is > best as it is, a limited solution for ENUM. Well I definitely lack the time or resources to take on such a sisyphian task, which I guess is the reason for send-n in the first place? Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 03:15:54 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EE83A69CF; Fri, 4 Jul 2008 03:15:54 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2708A3A69CF for ; Fri, 4 Jul 2008 03:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TOD6UmppFSL for ; Fri, 4 Jul 2008 03:15:53 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id D6CCD3A69AB for ; Fri, 4 Jul 2008 03:15:52 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=kgwdBQ7GfR/0hlTAsr0VuvYffZOVW4cW1iKyN0KNSEpp5S1E6B6FDT6b /QzEClt7CdLPVzW0yvYYSln333dihDHdMSatsTSjIVuuSc79hgIkOqrqj XBHrO1QkpsB6LGE; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215166561; x=1246702561; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Jay=20Daley"=20|Subject:=20 Re:=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20is sues|Date:=20Fri,=204=20Jul=202008=2011:15:45=20+0100 |Message-ID:=20|To:=20"Brian=20Rosen"=20 |Cc:=20enum@ietf.org|MIME-Version:=201 .0|In-Reply-To:=20<03e001c8dd69$0b950800$e76af444@cis.neu star.com>|References:=20<018901c8dcb3$9f 3f1f70$e76af444@cis.neustar.com>=0D=0A=09=0D=0A=09<02dc01c8dd22$0e684480$e76af444@cis.neustar.com >=09=20<03e001c8dd69$0b950800$e76af444@c is.neustar.com>; bh=zc0SH+/7dvvwvFNtzkJCxdBjfrXmd8Zf6fZPx34QOM8=; b=k3n8VjUXKPhAwePD4bgzpOPVjW5UFYJQR37F8Ym3xVDZfxc+V8hf7tf3 Wtfo5VuyZCb++mv0JSrgYEPlhQzkVwqtXgzBza7QF+BXsMh8mOh5+O067 TfxgSCKKZ0iqSwp; X-IronPort-AV: E=Sophos;i="4.30,302,1212361200"; d="scan'208";a="3899588" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 04 Jul 2008 11:15:59 +0100 In-Reply-To: <03e001c8dd69$0b950800$e76af444@cis.neustar.com> References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Jay Daley" Date: Fri, 4 Jul 2008 11:15:45 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/07/2008 11:15:58 AM, Serialize complete at 04/07/2008 11:15:58 AM Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian > Nah, I don't think you will preload everything, just cache what you use the > most. Download whatever else you need on demand. Whether you preload or cache and download on demand, is still the same thing. Your solution means any device that will do ENUM lookups needs access to a great big database. > > The data I'm proposing gives you validation of number length. It doesn't > tell you that you have a working number. Exactly!! Which is why we need send-n. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 03:28:55 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AFC3A6B4A; Fri, 4 Jul 2008 03:28:54 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B383A6B4A for ; Fri, 4 Jul 2008 03:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQoYX2b-QAPi for ; Fri, 4 Jul 2008 03:28:54 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id A42623A6B3E for ; Fri, 4 Jul 2008 03:28:53 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=A5fjx38m0J/lXUkjLXyOkQSZl3Jl0XtpJxMU6GL/mNktyq2H1I0GwIlH WagFfpTKKG8HBQNFOKevGC3SsX3tN85LcyKdQHiSAH+TSJn0p8W+mRMxm HjXW5Q8aT2tHp+q; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215167342; x=1246703342; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Jay=20Daley"=20|Subject:=20 Re:=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20is sues|Date:=20Fri,=204=20Jul=202008=2011:28:46=20+0100 |Message-ID:=20|To:=20"Brian=20Rosen"=20 |Cc:=20enum@ietf.org|MIME-Version:=201 .0|In-Reply-To:=20<03e001c8dd69$0b950800$e76af444@cis.neu star.com>|References:=20<018901c8dcb3$9f 3f1f70$e76af444@cis.neustar.com>=0D=0A=09=0D=0A=09<02dc01c8dd22$0e684480$e76af444@cis.neustar.com >=09=20<03e001c8dd69$0b950800$e76af444@c is.neustar.com>; bh=6CmEt5GMcyJs08eA9P1vDuTNOu8qI8jUvky47eilVNg=; b=VYs526iHOcfR31KBxVGuKcEaeROp9HMGa6RVu3WonpwessNEnAVx7abv +iBk3fN4pKjQxAotIyB8WOi9eLsETGw27qKQr8Ze6BGCLNWfnSN1PF022 e1RBjnAvlkN+EYL; X-IronPort-AV: E=Sophos;i="4.30,302,1212361200"; d="scan'208";a="4742424" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Jul 2008 11:29:00 +0100 In-Reply-To: <03e001c8dd69$0b950800$e76af444@cis.neustar.com> References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Jay Daley" Date: Fri, 4 Jul 2008 11:28:46 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/07/2008 11:29:00 AM, Serialize complete at 04/07/2008 11:29:00 AM Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Here's a much simpler way of putting it: Your proposal can tell whether there *could be* a number of a particular length, send-n can tell whether there *is* a number of a particular length. send-n is only about one tree, your proposal may cover multiple trees. These are two very different, but complementary, requirements. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 03:35:23 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0263A6C0C; Fri, 4 Jul 2008 03:35:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07143A6C0C for ; Fri, 4 Jul 2008 03:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD1WgkSHBIJq for ; Fri, 4 Jul 2008 03:35:22 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id DDBCC3A6BE8 for ; Fri, 4 Jul 2008 03:35:21 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 65605FF26C for ; Fri, 4 Jul 2008 20:35:29 +1000 (EST) Message-ID: <486DFCE9.9030002@e164.org> Date: Fri, 04 Jul 2008 20:35:21 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jay Daley wrote: > Exactly!! Which is why we need send-n. Just because you need a solution to a problem doesn't mean it must replicate what PSTN systems already do that's just crazy. Has no one actually got a valid criticism for my suggestion of doing this as a routing type protocol rather than this hack job on ENUM? Seems most ignored my suggestion completely except for one remark about TRIP. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 03:42:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B343A6B6E; Fri, 4 Jul 2008 03:42:22 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619113A6B63 for ; Fri, 4 Jul 2008 03:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6qN+KDCkvJi for ; Fri, 4 Jul 2008 03:42:20 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 2DFEE3A69CF for ; Fri, 4 Jul 2008 03:42:20 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KEikF-0002mC-2p; Fri, 04 Jul 2008 12:42:27 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 5D35C774EEE; Fri, 4 Jul 2008 12:42:28 +0200 (CEST) Date: Fri, 4 Jul 2008 12:42:28 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080704104228.GB4193@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <1775503D-350B-4F65-BD46-36BD97BDC320@games-with-brains.com> <8D9E8C74-51BF-412A-A934-350E61D15F7B@games-with-brains.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8D9E8C74-51BF-412A-A934-350E61D15F7B@games-with-brains.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Fri, Jul 04, 2008 at 02:08:20AM +0100, Eleanor McHugh wrote: > a. it solves the number length problem in ENUM may I ask for a description of this problem? What is the input and what is the desired output? > b. it allows the shape of portions of the DNS tree to be specified and > validated The problem here is that it doesn't buy you much in the general DNS case. There you face the fact that hierarchy in the name space does neither follow nor imply administrative hierarchy (or control, if you wish). So, while under certain circumstances you might be able to make statements about the current shape of the tree, you're likely not in a position to communicate rules. For this reason finding a use case could become hard. However, the situtation is slightly different in the case of ENUM since there is some hierarchy in the e.164 space. However, the applicability is dependent on which part of the tree you're in since the rules, including who actually sets the lengths of certain number ranges, vary by country. > I've missed something in my interpretation of the send-n draft as I > don't see how using a non-NAPTR resource to achieve the same effect > makes any difference. In both cases the RR is making statements about > the shape of the tree beneath the current level. >From a DNS perspective, another RR type would be cleaner; however, the question is whether you're actually describing a property of the DNS or a property of the data that is put into the DNS. This may sound like splitting hairs, but the length and completeness issues are around the e.164 numbers, not necessarily the DNS representation, even though there is a very straightforward mapping. Anyway, the basic reason use of NAPTR (with which I've voiced my discomfort before) is that that's what you ask for so it can "nicely" be put into the DNS repsonse. Another RR type would have to be asked for explicitly _or_ some DNS rules would have to be changed (or gravity, whatever comes easier) to insert this new RR type (or any one, the problem isn't the novelty of the type) into the additional information of the response. This is yet another example where DNS is that ultimater best fit for ENUM/I-ENUM, just needs these little tewaks ... -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 11:58:51 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205AE3A6918; Fri, 4 Jul 2008 11:58:51 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C463A6918 for ; Fri, 4 Jul 2008 11:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hur19jCzz+Q4 for ; Fri, 4 Jul 2008 11:58:45 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 89A903A68AB for ; Fri, 4 Jul 2008 11:58:45 -0700 (PDT) Received: from 72-58-1-24.area3.spcsdns.net ([72.58.1.24] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEqUU-0008LS-2E; Fri, 04 Jul 2008 13:58:46 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com><02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> Date: Fri, 4 Jul 2008 14:58:43 -0400 Message-ID: <01df01c8de07$ffdefbc0$18013a48@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjd/moBKchKRxGFS/+5rZII3KP3+wACF4WQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org No. Send-n can't necessarily tell you that unless the ENUM tree is provisioned with each separate number. Real systems don't necessarily do that. Many, including ours, lets you provision a range of numbers, and you won't be able to tell if the number is actually valid unless you try it. That is what I meant. The information on number length is not equivalent to working number, and never could be. Brian > -----Original Message----- > From: Jay Daley [mailto:jay@nominet.org.uk] > Sent: Friday, July 04, 2008 6:29 AM > To: Brian Rosen > Cc: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > Here's a much simpler way of putting it: > > Your proposal can tell whether there *could be* a number of a particular > length, send-n can tell whether there *is* a number of a particular > length. > > send-n is only about one tree, your proposal may cover multiple trees. > > These are two very different, but complementary, requirements. > > Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 12:04:49 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A473A68AB; Fri, 4 Jul 2008 12:04:49 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77CB3A6851 for ; Fri, 4 Jul 2008 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EeqMkf9bV30 for ; Fri, 4 Jul 2008 12:04:48 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 35DC83A6834 for ; Fri, 4 Jul 2008 12:04:48 -0700 (PDT) Received: from 72-58-1-24.area3.spcsdns.net ([72.58.1.24] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KEqaO-00009O-0Y; Fri, 04 Jul 2008 14:04:49 -0500 From: "Brian Rosen" To: "'Duane'" , References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> Date: Fri, 4 Jul 2008 15:04:50 -0400 Message-ID: <01ef01c8de08$d7f01800$18013a48@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <486DFCE9.9030002@e164.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjd/dYwkLSQQpLYRomjK5/4oBGDJwACizuA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org As I said, I don't much care exactly how we get number length, as long as it's the full length in some reasonably complete form. The general problem of distributing the data is hard, because regulators, carriers and even enterprises are the authoritative source, and getting all of them to cooperate and be trustworthy to each other is hard. Brian > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Duane > Sent: Friday, July 04, 2008 6:35 AM > To: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > Jay Daley wrote: > > > Exactly!! Which is why we need send-n. > > Just because you need a solution to a problem doesn't mean it must > replicate what PSTN systems already do that's just crazy. > > Has no one actually got a valid criticism for my suggestion of doing > this as a routing type protocol rather than this hack job on ENUM? > > Seems most ignored my suggestion completely except for one remark about > TRIP. > > -- > > Best regards, > Duane > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 4 12:14:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C163A6B5B; Fri, 4 Jul 2008 12:14:34 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740323A6A76 for ; Fri, 4 Jul 2008 12:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdoC4v+i5AEi for ; Fri, 4 Jul 2008 12:14:31 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id CC4E43A6B5B for ; Fri, 4 Jul 2008 12:14:31 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 6AAA3FF26F for ; Sat, 5 Jul 2008 05:14:40 +1000 (EST) Message-ID: <486E7692.5040904@e164.org> Date: Sat, 05 Jul 2008 05:14:26 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com> <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <01ef01c8de08$d7f01800$18013a48@cis.neustar.com> In-Reply-To: <01ef01c8de08$d7f01800$18013a48@cis.neustar.com> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian Rosen wrote: > The general problem of distributing the data is hard, because regulators, > carriers and even enterprises are the authoritative source, and getting all > of them to cooperate and be trustworthy to each other is hard. Isn't the same true of BGP? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jul 5 01:49:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A217B3A6B23; Sat, 5 Jul 2008 01:49:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FA83A6AF6 for ; Sat, 5 Jul 2008 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNrGVJVA8VPt for ; Sat, 5 Jul 2008 01:49:06 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 13D903A6B23 for ; Sat, 5 Jul 2008 01:49:05 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=3XS56xItWglsFIO+fO1UD029N18UcEemM/hjz/IRl6aq4WeWU7iNZzdc hbmV4K7RW7CT0Ow4r11dvQ8wQrj242PpJzIvyYtI0ss3CrcJaBt0t0t6S JHR0koi8KeRpOmO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215247746; x=1246783746; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Re :=20[Enum]=20Send-n,=20=20rat=20holes=20and=20real=20issu es|Date:=20Sat,=205=20Jul=202008=2009:49:01=20+0100 |Message-ID:=20|To:=20"Brian=20Rosen"=20 |Cc:=20enum@ietf.org|MIME-Version:=201 .0|In-Reply-To:=20<01df01c8de07$ffdefbc0$18013a48@cis.neu star.com>|References:=20<018901c8dcb3$9f 3f1f70$e76af444@cis.neustar.com><02dc01c 8dd22$0e684480$e76af444@cis.neustar.com>=0D=0A=09=0D=0A=09<03e001c8dd69$0b950800$e76af444@cis.neu star.com>=09=20<01df01c8de07$ffdefbc0$18 013a48@cis.neustar.com>; bh=gumuNyjzvXPIWHzfeJjj8gmji6ImRzcCuYEvh4/5odg=; b=ZvcogkgrkPwpJluqxmHdCy6ND8jDjKpnAWzLJGC6Pv7Kyx56gJiN2mIY DRwYglRNP1y/HsgWx7TpB1tKxkk5fjfHm+uLacdlNdEUJPwIl8ztrZSfQ gjzfzhOZbFO2VJW; X-IronPort-AV: E=Sophos;i="4.30,306,1212361200"; d="scan'208";a="4768183" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 05 Jul 2008 09:49:04 +0100 In-Reply-To: <01df01c8de07$ffdefbc0$18013a48@cis.neustar.com> References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com><02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <01df01c8de07$ffdefbc0$18013a48@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Sat, 5 Jul 2008 09:49:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 05/07/2008 09:49:04 AM, Serialize complete at 05/07/2008 09:49:04 AM Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian > No. > > Send-n can't necessarily tell you that unless the ENUM tree is provisioned > with each separate number. Real systems don't necessarily do that. Many, > including ours, lets you provision a range of numbers, and you won't be able > to tell if the number is actually valid unless you try it. That is what I > meant. The information on number length is not equivalent to working > number, and never could be. Eh? I have no idea what the first three sentences of that paragraph mean. I'd be grateful if you could have another go at explaining that. I understand your last sentence from your perspective - that a number with an identified SIP endpoint may still not be "working" but I don't get the logic of how it applies here - you are quite right that send-n can't deal with that but then neither can anything else! Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From c.langland@chriger.no Sun Jul 6 22:45:28 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E283A6A56; Sun, 6 Jul 2008 22:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.695 X-Spam-Level: X-Spam-Status: No, score=-58.695 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67Iq-2ffRjiR; Sun, 6 Jul 2008 22:45:26 -0700 (PDT) Received: from 190-82-221-123.adsl.tie.cl (190-82-221-123.adsl.tie.cl [190.82.221.123]) by core3.amsl.com (Postfix) with SMTP id 9A8673A6A3D; Sun, 6 Jul 2008 22:45:01 -0700 (PDT) X-Originating-IP: 0.212.203.57 by smtp.190.82.221.123; Mon, 07 Jul 2008 01:45:05 -0500 Message-ID: From: "Mayra Bernal" Reply-To: "Mayra Bernal" To: edu-discuss-request@ietf.org Subject: Replica rolex watches! SAVE Big! Date: Mon, 07 Jul 2008 01:45:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://johnwalkerblog.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://johnwalkerblog.blogspot.com/ From enum-bounces@ietf.org Mon Jul 7 00:43:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526AF28C12D; Mon, 7 Jul 2008 00:43:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC2828C12D for ; Mon, 7 Jul 2008 00:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.029 X-Spam-Level: * X-Spam-Status: No, score=1.029 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34iPd0Xp5N1Z for ; Mon, 7 Jul 2008 00:43:45 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id D1B9228C12A for ; Mon, 7 Jul 2008 00:43:44 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1KFlNv-0003tp-00; Mon, 07 Jul 2008 09:43:43 +0200 Date: Mon, 7 Jul 2008 09:43:43 +0200 From: Otmar Lendl To: Duane Message-ID: <20080707074343.GA14529@nic.at> Mail-Followup-To: Otmar Lendl , Duane , "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <486DFCE9.9030002@e164.org> User-Agent: Mutt/1.5.9i Cc: "enum@ietf.org" Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2008/07/04 12:07, Duane wrote: > Jay Daley wrote: > > > Exactly!! Which is why we need send-n. > > Just because you need a solution to a problem doesn't mean it must > replicate what PSTN systems already do that's just crazy. > > Has no one actually got a valid criticism for my suggestion of doing > this as a routing type protocol rather than this hack job on ENUM? > > Seems most ignored my suggestion completely except for one remark about > TRIP. We (including speermint) have been though that discussion already a few times. A BGP-like protocol for numbers (or better: prefixes) just won't scale. One part of what makes BGP work for IP routing is the aggregation properties of IP addresses: large blocks are given to ISPs, which give out smaller blocks to enterprises, or just individual addresses to end-users. The rest of the world doesn't care how this ISPs handed out addresses, a single entry in the global routing table suffices. It used to be the case that phone numbers worked in a similar fashion: country codes, block allocation, individual number assignment. Perfect for prefix-based routing. Now add one table-spoon of "number portability" to your stew, season it with "premium rate" and "freephone" numbers and watch your routing tables explode. More technically: phone numbers used to be addresses. Now they are names. It used to be that the equivalent of phone numbers were IP addresses. This no longer holds. If you really want to compare them to Internet objects, take domain names. So, how do *you* like the idea of a BGP like routing protocol for domain names? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 05:14:14 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8973A698B; Mon, 7 Jul 2008 05:14:14 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAF53A6A56 for ; Mon, 7 Jul 2008 05:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtxnUJZLpHUo for ; Mon, 7 Jul 2008 05:14:12 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 98FFF3A6919 for ; Mon, 7 Jul 2008 05:14:12 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 1B3A15AC572 for ; Mon, 7 Jul 2008 22:14:16 +1000 (EST) Message-ID: <4872086A.5090602@e164.org> Date: Mon, 07 Jul 2008 22:13:30 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> In-Reply-To: <20080707074343.GA14529@nic.at> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > We (including speermint) have been though that discussion already > a few times. A BGP-like protocol for numbers (or better: prefixes) > just won't scale. Why would DNS scale any better? > One part of what makes BGP work for IP routing is the aggregation > properties of IP addresses: large blocks are given to ISPs, which give > out smaller blocks to enterprises, or just individual addresses to > end-users. Lets be clear here, we're not talking about routing, just prefixes and there is a HUGE difference because there is much less problems with security implications at the very least. > The rest of the world doesn't care how this ISPs handed out addresses, a > single entry in the global routing table suffices. Again, you are confusing things here between prefixes and routing, we're not talking about routing just prefix lengths, the rest of your comments are along the same line. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 06:27:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49423A6A48; Mon, 7 Jul 2008 06:27:18 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AC93A6A48 for ; Mon, 7 Jul 2008 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ih-9woOazac for ; Mon, 7 Jul 2008 06:27:16 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 1613B3A690B for ; Mon, 7 Jul 2008 06:27:15 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1KFqkL-0003wm-00; Mon, 07 Jul 2008 15:27:13 +0200 Date: Mon, 7 Jul 2008 15:27:13 +0200 From: Otmar Lendl To: Duane Message-ID: <20080707132713.GA15159@nic.at> Mail-Followup-To: Otmar Lendl , Duane , "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4872086A.5090602@e164.org> User-Agent: Mutt/1.5.9i Cc: "enum@ietf.org" Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2008/07/07 14:07, Duane wrote: > Otmar Lendl wrote: > > > We (including speermint) have been though that discussion already > > a few times. A BGP-like protocol for numbers (or better: prefixes) > > just won't scale. > > Why would DNS scale any better? > Compare the # of domains out there with the number of routes in the global BGP routing table. Roughly, there are 3 orders of magnitudes between the two. > > The rest of the world doesn't care how this ISPs handed out addresses, a > > single entry in the global routing table suffices. > > Again, you are confusing things here between prefixes and routing, we're > not talking about routing just prefix lengths, the rest of your comments > are along the same line. Think. Who announces a length for a prefix? The carrier (or enterprise) who operates the prefix. Given any leeway from the NRA, he is the only one who definitly knows. Any porting operation leads to someone to announce the length of the number/prefix he just ported in. With open numbering plans, this ported number does not need to have the same length as before. Thus, taking open numbering plans into account, the size of the BGP-like *whatever* table is O(#blocks + #ported numbers). /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 07:48:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F3F28C16B; Mon, 7 Jul 2008 07:48:16 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C093428C19F for ; Mon, 7 Jul 2008 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-5yNj8Fcy3n for ; Mon, 7 Jul 2008 07:48:13 -0700 (PDT) Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 1537328C16E for ; Mon, 7 Jul 2008 07:46:43 -0700 (PDT) Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m67Ekd0Z024844; Mon, 7 Jul 2008 10:46:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4872086A.5090602@e164.org> References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> Date: Mon, 7 Jul 2008 10:40:32 -0400 To: Duane From: Edward Lewis X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Cc: "enum@ietf.org" Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 22:13 +1000 7/7/08, Duane wrote: >Otmar Lendl wrote: Otmar made some good observations. >> We (including speermint) have been though that discussion already >> a few times. A BGP-like protocol for numbers (or better: prefixes) >> just won't scale. > >Why would DNS scale any better? DNS scales larger than BGP in the sense that the data held by DNS does not travel like the data held by BGP. Let's say you have 10,000,000 phone numbers with number portability. In DNS I would need to have 10,000,000 NAPTR sets residing in a handful of servers (all under my administrative control) in key places. In BGP, without aggregation, I would have to see that 10,000,000 route entries would have to be sent to all of the routing points globally, not all under my control. That's the idea in a nutshell - DNS does not attempt to move the data model everywhere, BGP does. (Note - this is not a stab at BGP, the jobs of the two protocols are different.) >> One part of what makes BGP work for IP routing is the aggregation >> properties of IP addresses: large blocks are given to ISPs, which give >> out smaller blocks to enterprises, or just individual addresses to >> end-users. > >Lets be clear here, we're not talking about routing, just prefixes and >there is a HUGE difference because there is much less problems with >security implications at the very least. I think the point Otmar is making is that when you look at a IPv4 address, the first N bits determine where all the 32-N bit addresses are. I.e., a 10.10.10/24 route (if none are more specific) will be the path for all 256 numbers in 10.10.10.0-255. But for +1-571-555, not all 10,000 below what will be routed the same way. The obsevation of Otmar that I think is great is that telephone numbers, when backed by number portability, are no longer network addresses but are network names. Yet, an IP address is just an address, not a name. A lookup service (like DNS) or a directory/database deals with names better than addresses, a routing service deals with addresses better than names. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 09:53:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBCC3A6ABD; Mon, 7 Jul 2008 09:53:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54923A6ABD for ; Mon, 7 Jul 2008 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjk98DxO-KHX for ; Mon, 7 Jul 2008 09:53:45 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id B50E23A6AA5 for ; Mon, 7 Jul 2008 09:53:44 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KFtyF-0004WQ-L9; Mon, 07 Jul 2008 18:53:47 +0200 Received: from localhost by x27.adm.denic.de with local id 1KFtxD-0003xv-S7; Mon, 07 Jul 2008 18:52:43 +0200 Date: Mon, 7 Jul 2008 18:52:43 +0200 From: Peter Koch To: Edward Lewis Message-ID: <20080707165243.GA13475@x27.adm.denic.de> Mail-Followup-To: Edward Lewis , IETF ENUM WG References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IETF ENUM WG Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Mon, Jul 07, 2008 at 10:40:32AM -0400, Edward Lewis wrote: > address, not a name. A lookup service (like DNS) or a > directory/database deals with names better than addresses, a routing > service deals with addresses better than names. that depends on the properties of the number space used for these addresses. DNS lacks some of the BGP features that are implicitly asked for here, be that visibility (application of filters) or response modification based on client identity. The question whether the IP address space or the E.164 space will turn out to be "more flat" in the end is moot, say: "PI". Well, multihoming is another interesting, albeit unrelated, issue. So, with a BGP model being "worse" that doesn't make "DNS" a good choice, just a less bad one. And there are other protocols that might fit even better: using IRIS+RFC 4414 as a substrate could solve a couple of problems at once. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 11:34:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298CA3A681C; Mon, 7 Jul 2008 11:34:27 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598D13A6887 for ; Mon, 7 Jul 2008 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuUDApgJ6TiF for ; Mon, 7 Jul 2008 11:34:24 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 56C6E3A681C for ; Mon, 7 Jul 2008 11:34:24 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KFvXb-0002PM-34; Mon, 07 Jul 2008 13:34:23 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <018901c8dcb3$9f3f1f70$e76af444@cis.neustar.com><02dc01c8dd22$0e684480$e76af444@cis.neustar.com><03e001c8dd69$0b950800$e76af444@cis.neustar.com> <01df01c8de07$ffdefbc0$18013a48@cis.neustar.com> Date: Mon, 7 Jul 2008 14:34:25 -0400 Message-ID: <080c01c8e060$17ea9170$4101a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjee/v8ZjN3s0YZQ461jvL50wOQmwB4s2Gg In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In our enum implementation, the number holder (carrier) can provision an entire range of numbers with a single provisioning action. If the "pattern" of the NAPTRs is the same, then provisioning is simplified. A query to any number in the range will return a result determined by pattern. NAPTRs use regexps, and we use that. So, the rule may be (details omitted) sip:\1@gateway.example.net;user=phone, and could be applied to a range, say +4412340000 through +4412349999 The provisioning action may apply to the entire range. There is no requirement that each and every number in the range be active (what I meant by "working"). An enum query to +4412341234 would return sip:+4412341234@gateway.example.net;user=phone Nothing fancy, but you can't infer that +4412341234 is a valid number with active service. Brian > -----Original Message----- > From: Jay Daley [mailto:jay@nominet.org.uk] > Sent: Saturday, July 05, 2008 4:49 AM > To: Brian Rosen > Cc: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > Brian > > > No. > > > > Send-n can't necessarily tell you that unless the ENUM tree is > provisioned > > with each separate number. Real systems don't necessarily do that. > Many, > > including ours, lets you provision a range of numbers, and you won't be > able > > to tell if the number is actually valid unless you try it. That is what > I > > meant. The information on number length is not equivalent to working > > number, and never could be. > > Eh? I have no idea what the first three sentences of that paragraph mean. > I'd be grateful if you could have another go at explaining that. > > I understand your last sentence from your perspective - that a number with > an identified SIP endpoint may still not be "working" but I don't get the > logic of how it applies here - you are quite right that send-n can't deal > with that but then neither can anything else! > > Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 14:00:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F78428C198; Mon, 7 Jul 2008 14:00:02 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9D593A6B64; Mon, 7 Jul 2008 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707210001.B9D593A6B64@core3.amsl.com> Date: Mon, 7 Jul 2008 14:00:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-trunkgroup-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for an Enumservice Trunkgroup Author(s) : R. Shockey, T. Creighton Filename : draft-ietf-enum-trunkgroup-00.txt Pages : 10 Date : 2008-07-07 This document registers the Enumservice 'trunk' and subtypes 'sip' and 'tel' using the URI schemes 'sip:' and 'tel:' as per the IANA registration process defined in the ENUM specification RFC 3761 [RFC7761]. RFC 4904 [RFC4904] defines a technique for the conveyance of carrying trunking information in SIP [RFC3261] and or TEL [RFC3966] URI's. This Enumservice provides a mechanism for ENUM databases residing in service provider networks a mechanism to query for that data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-trunkgroup-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-trunkgroup-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-07134722.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Jul 7 17:32:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9383A6BAC; Mon, 7 Jul 2008 17:32:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531713A6BAB for ; Mon, 7 Jul 2008 17:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyecLaHigD8o for ; Mon, 7 Jul 2008 17:32:44 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 818F93A6BA7 for ; Mon, 7 Jul 2008 17:32:44 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 234295AC57E for ; Tue, 8 Jul 2008 10:32:52 +1000 (EST) Message-ID: <4872B581.7050702@e164.org> Date: Tue, 08 Jul 2008 10:32:01 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> In-Reply-To: <20080707132713.GA15159@nic.at> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > Compare the # of domains out there with the number of routes in the > global BGP routing table. Roughly, there are 3 orders of magnitudes > between the two. Ok I think things are getting confused between routing and prefix lengths here again. If route information is store there would be a lot of data, if only prefix information is stored you store the general cases then simply add exceptions as needed, the 1% Brian was pointing out in an email the other day. > Who announces a length for a prefix? The carrier (or enterprise) who > operates the prefix. Given any leeway from the NRA, he is the only > one who definitly knows. > > Any porting operation leads to someone to announce the length of the > number/prefix he just ported in. With open numbering plans, this ported > number does not need to have the same length as before. > > Thus, taking open numbering plans into account, the size of the > BGP-like *whatever* table is O(#blocks + #ported numbers). You are thinking about this wrong, the only time someone needs to announce a prefix is if the length is different, countries with fixed length dial plans would have very few entries. Take Australia for example, I downloaded the entire file of allocated numbers from the regulator a while back and ran a script across it. http://www.e164.org/wiki/AU_Dialplan For the entire country there is only 30 or 40 lines to describe the entire prefix set 100% perfectly, this includes numbers that have been ported, free phone numbers, so on an so forth. Lets be clear here, we're only dealing with prefix lengths, and only those that vary need to be stored as exceptions from the majority. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 7 17:36:00 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B230928C14D; Mon, 7 Jul 2008 17:36:00 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B3228C14D for ; Mon, 7 Jul 2008 17:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHyJIp9r95i5 for ; Mon, 7 Jul 2008 17:35:59 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 64BEE3A6BB4 for ; Mon, 7 Jul 2008 17:35:59 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 130895AC57E for ; Tue, 8 Jul 2008 10:36:08 +1000 (EST) Message-ID: <4872B646.9060700@e164.org> Date: Tue, 08 Jul 2008 10:35:18 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075634711==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1075634711== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig561BEC887995638DBE85632D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig561BEC887995638DBE85632D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Edward Lewis wrote: > DNS scales larger than BGP in the sense that the data held by DNS does > not travel like the data held by BGP. Let's say you have 10,000,000 > phone numbers with number portability. But we're not talking about routing, we're talking about prefixes. > I think the point Otmar is making is that when you look at a IPv4 > address, the first N bits determine where all the 32-N bit addresses > are. I.e., a 10.10.10/24 route (if none are more specific) will be the= > path for all 256 numbers in 10.10.10.0-255. But for +1-571-555, not al= l > 10,000 below what will be routed the same way. Exactly, the problem is very similar, you can list the average case, Brian's 99% and then the 1% exception you simply fill in the records as needed. > The obsevation of Otmar that I think is great is that telephone numbers= , > when backed by number portability, are no longer network addresses but > are network names. Yet, an IP address is just an address, not a name. = > A lookup service (like DNS) or a directory/database deals with names > better than addresses, a routing service deals with addresses better > than names. Number portability has *NOTHING* to do with prefix lengths. unless the owner suddenly decides to increase the number space. --=20 Best regards, Duane --------------enig561BEC887995638DBE85632D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcrZGEpWoZMmo/c8RAmAiAKCWvjWG7DNx6amTw+GzA7LalPw6cwCgpKng vZlT2lNZ2CtHT2SNSjjJsi0= =CQC9 -----END PGP SIGNATURE----- --------------enig561BEC887995638DBE85632D-- --===============1075634711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --===============1075634711==-- From enum-bounces@ietf.org Tue Jul 8 02:54:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBF23A6A65; Tue, 8 Jul 2008 02:54:52 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CEA28C153 for ; Tue, 8 Jul 2008 02:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-LmalsFoIie for ; Tue, 8 Jul 2008 02:54:49 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 6DF593A6A47 for ; Tue, 8 Jul 2008 02:54:48 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1KG9uL-0004B8-00; Tue, 08 Jul 2008 11:54:49 +0200 Date: Tue, 8 Jul 2008 11:54:49 +0200 From: Otmar Lendl To: Duane Message-ID: <20080708095449.GA16020@nic.at> Mail-Followup-To: Otmar Lendl , Duane , "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4872B581.7050702@e164.org> User-Agent: Mutt/1.5.9i Cc: "enum@ietf.org" Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2008/07/08 02:07, Duane wrote: > Otmar Lendl wrote: > > > Who announces a length for a prefix? The carrier (or enterprise) who > > operates the prefix. Given any leeway from the NRA, he is the only > > one who definitly knows. > > > > Any porting operation leads to someone to announce the length of the > > number/prefix he just ported in. With open numbering plans, this ported > > number does not need to have the same length as before. > > > > Thus, taking open numbering plans into account, the size of the > > BGP-like *whatever* table is O(#blocks + #ported numbers). > > You are thinking about this wrong, the only time someone needs to > announce a prefix is if the length is different, countries with fixed > length dial plans would have very few entries. If it were that easy everywhere and in all cases, we would not be talking about this. > Take Australia for example, I downloaded the entire file of allocated > numbers from the regulator a while back and ran a script across it. Doesn't surprise me. Now do the same trick for Austria and Germany. In the .au case, your sole data-source is the NRA. If that would hold everwhere, then Brian's proposal could work: these numbering-plans could be easily aggregated into a single database. (Why the hell you want to do something BGP like for that, I just can't grasp.) The trouble, and the reason for the send-n proposal, is the fact that the NRA of .uk does NOT know the number lengths for all numbers in its country-code. The same holds for .at, .de and probably a few more. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 03:46:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4625728C169; Tue, 8 Jul 2008 03:46:57 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FBE28C169 for ; Tue, 8 Jul 2008 03:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0VfY4uMVsDJ for ; Tue, 8 Jul 2008 03:46:55 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 1949428C165 for ; Tue, 8 Jul 2008 03:46:54 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 5AADF5AC564 for ; Tue, 8 Jul 2008 20:47:03 +1000 (EST) Message-ID: <48734571.30009@e164.org> Date: Tue, 08 Jul 2008 20:46:09 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> In-Reply-To: <20080708095449.GA16020@nic.at> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > The trouble, and the reason for the send-n proposal, is the fact that > the NRA of .uk does NOT know the number lengths for all numbers in its > country-code. The same holds for .at, .de and probably a few more. I'm guessing the UK is more inline with Australia than Austria, well Australia would have copied the UK but in any case, from what has been expressed the problem as I see it is that the majority of routes follow a fixed dial plan but there are exceptions and the whole point of send-n is to cover the exceptions. Can someone in the UK doing send-n please give us a rough idea of the ratio of known and unknown rather than everyone keep speculating over the scale of this. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 04:03:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9F728C165; Tue, 8 Jul 2008 04:03:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D0028C165 for ; Tue, 8 Jul 2008 04:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtQZV67pne7N for ; Tue, 8 Jul 2008 04:03:23 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B80653A6810 for ; Tue, 8 Jul 2008 04:03:22 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=DfQaCVPe7kVg2IMOWNf8AsU2nb+yM0UtpIe2erGtZqdggC7opGWSNOdv tzlOUrknDsrlo7zj/QZw1CUUAEKYtBg2NhlWMXhZkMAKi/yEMdOqoYaS0 U3Eyr1PNaDCYCsl; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215515012; x=1247051012; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-n,=20=20rat=20holes=20and=20real=20issues|Date: =20Tue,=208=20Jul=202008=2012:03:25=20+0100|Message-ID: =20|To:=20enum@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<48734571.30009@e164.org>|References: =20=0D=0A=09<02dc01c8dd22$0e684480$e76af 444@cis.neustar.com>=09=0D=0A=09<03e001c 8dd69$0b950800$e76af444@cis.neustar.com>=09=0D=0A=09<486DFCE9.9030002@e164.org>=09<20080707074343 .GA14529@nic.at>=09<4872086A.5090602@e164.org>=0D=0A=09<2 0080707132713.GA15159@nic.at>=09<4872B581.7050702@e164.or g>=09<20080708095449.GA16020@nic.at>=20<48734571.30009@e1 64.org>; bh=f+wrkJTmqOVhMtNlX1dvNjCA4m+aolkRoJdHAaEJHNQ=; b=H++NzOe9xpgGot7F4D4YjCOTyCtF/INORCEzUO+4iOCPRz4qynbY11Fs EMVr4X5qwTm6ujbAuqmh8M+ISftkgbEskZK6OE4g2GbUKFlTU+FsMnnEe NSW81wE+0tXd5Kb; X-IronPort-AV: E=Sophos;i="4.30,323,1212361200"; d="scan'208";a="3981546" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 08 Jul 2008 12:03:29 +0100 In-Reply-To: <48734571.30009@e164.org> References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <48734571.30009@e164.org> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 8 Jul 2008 12:03:25 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/07/2008 12:03:29 PM, Serialize complete at 08/07/2008 12:03:29 PM Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Can someone in the UK doing send-n please give us a rough idea of the > ratio of known and unknown rather than everyone keep speculating over > the scale of this. As far as I know the UK regulator does actually have a very good idea of the number lengths, although the published information isn't always 100% up-to-date. The UK issue is the very large size of the prefix->length table, and the need to accurately maintain it in every switch in the UK telephone network. Currently a mixture of static tables and ISUP SND is used, but with NGN interconnect over IP coming soon the latter method won't be available. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 04:05:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A353A6A53; Tue, 8 Jul 2008 04:05:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC033A6845 for ; Tue, 8 Jul 2008 04:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTNq1BLVSftz for ; Tue, 8 Jul 2008 04:05:02 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 5D8983A6810 for ; Tue, 8 Jul 2008 04:05:02 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id D97BF5AC57E for ; Tue, 8 Jul 2008 21:05:10 +1000 (EST) Message-ID: <487349B1.3020700@e164.org> Date: Tue, 08 Jul 2008 21:04:17 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <48734571.30009@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: >> Can someone in the UK doing send-n please give us a rough idea of the >> ratio of known and unknown rather than everyone keep speculating over >> the scale of this. > > As far as I know the UK regulator does actually have a very good idea of > the number lengths, although the published information isn't always 100% > up-to-date. Do you have a URI or data set I can run a script over? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 04:17:55 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2593A6A6C; Tue, 8 Jul 2008 04:17:55 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCF028C163 for ; Tue, 8 Jul 2008 04:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL9LYb40JVbI for ; Tue, 8 Jul 2008 04:17:48 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 468F73A6875 for ; Tue, 8 Jul 2008 04:17:47 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=M9L39ivVn+z4/yKQ4MLFvZRig8GIwN+O9gcHlMye3i/CFEe5NxsCgDJy 8ITPPSkDP+3Kz0K6zL5blIT+ZpuEvrnqnYXQGMHz0yQ+WhlYRyPc3mc6e fdLzTRYdOzwhzZa; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215515877; x=1247051877; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-n,=20=20rat=20holes=20and=20real=20issues|Date: =20Tue,=208=20Jul=202008=2012:17:54=20+0100|Message-ID: =20|To:=20enum@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<487349B1.3020700@e164.org> |References:=20=0D=0A=09<02dc01c8dd22$0e 684480$e76af444@cis.neustar.com>=09=0D =0A=09<03e001c8dd69$0b950800$e76af444@cis.neustar.com>=09 =0D=0A=09<486DFCE9.9030002@e164.org>=09< 20080707074343.GA14529@nic.at>=09<4872086A.5090602@e164.o rg>=0D=0A=09<20080707132713.GA15159@nic.at>=09<4872B581.7 050702@e164.org>=09<20080708095449.GA16020@nic.at>=0D=0A =09<48734571.30009@e164.org>=09=20<48734 9B1.3020700@e164.org>; bh=isYyYhDtbLb3FHa0QxGUhIZg+FzVzwU56HxY6UqKbPw=; b=T/oCCKYTk3Z4U7ajh+J+flZppt5OxxyM2dVVHC5JVW1znR6Bq2mJzZks mAUbgBpNRyMSFHZcHx3W8qlqhYgjWLApnHx/ckJHFtqME+dDTwjmArf3I lOjoWU76aJPlYaA; X-IronPort-AV: E=Sophos;i="4.30,323,1212361200"; d="scan'208";a="3981777" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 08 Jul 2008 12:17:56 +0100 In-Reply-To: <487349B1.3020700@e164.org> References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <48734571.30009@e164.org> <487349B1.3020700@e164.org> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 8 Jul 2008 12:17:54 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/07/2008 12:17:55 PM, Serialize complete at 08/07/2008 12:17:55 PM Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Do you have a URI or data set I can run a script over? It's all at http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/ Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 06:57:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496B83A69A0; Tue, 8 Jul 2008 06:57:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BD23A69A0 for ; Tue, 8 Jul 2008 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smP4sdUg-lsf for ; Tue, 8 Jul 2008 06:57:02 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id A67423A6A21 for ; Tue, 8 Jul 2008 06:57:02 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A10CDFF271 for ; Tue, 8 Jul 2008 23:57:09 +1000 (EST) Message-ID: <487371FE.2060608@e164.org> Date: Tue, 08 Jul 2008 23:56:14 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com> <03e001c8dd69$0b950800$e76af444@cis.neustar.com> <486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at> <4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at> <4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <48734571.30009@e164.org> <487349B1.3020700@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: >> Do you have a URI or data set I can run a script over? > > It's all at > http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/ Length is one of the fields in both the excel files and CSV files but doesn't seem to be in any rows, you said the regulators has a fair idea of this information, do they publish it at all? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 09:08:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DF03A686C; Tue, 8 Jul 2008 09:08:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6DE3A686C for ; Tue, 8 Jul 2008 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slYPtpqoSADJ for ; Tue, 8 Jul 2008 09:08:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 675473A6810 for ; Tue, 8 Jul 2008 09:08:42 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KGFkA-0001ZU-36; Tue, 08 Jul 2008 11:08:44 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , "'Duane'" References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com><03e001c8dd69$0b950800$e76af444@cis.neustar.com><486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at><4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at><4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> Date: Tue, 8 Jul 2008 12:08:41 -0400 Message-ID: <009101c8e114$e7737c40$1bd213ac@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080708095449.GA16020@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjg4LEuMrmeHhu8QAKjqaHhcty4XAAM5fZg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Please note that my proposal works in every circumstance. Each authoritative source of number length data provides the data for the part of the tree it is authoritative for. This could be a carrier, but it could even be an enterprise. It makes a small database. "Small" is in the current notion of databases. The kind of database where many of them fit in the disk drive of a US$250 computer. I can't imagine why any new system could possibly be concerned about keeping a cache of such a database. Since ENUM and this RR is new, we're talking about new systems. Brian > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Otmar Lendl > Sent: Tuesday, July 08, 2008 5:55 AM > To: Duane > Cc: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > On 2008/07/08 02:07, Duane wrote: > > Otmar Lendl wrote: > > > > > Who announces a length for a prefix? The carrier (or enterprise) who > > > operates the prefix. Given any leeway from the NRA, he is the only > > > one who definitly knows. > > > > > > Any porting operation leads to someone to announce the length of the > > > number/prefix he just ported in. With open numbering plans, this > ported > > > number does not need to have the same length as before. > > > > > > Thus, taking open numbering plans into account, the size of the > > > BGP-like *whatever* table is O(#blocks + #ported numbers). > > > > You are thinking about this wrong, the only time someone needs to > > announce a prefix is if the length is different, countries with fixed > > length dial plans would have very few entries. > > If it were that easy everywhere and in all cases, we would not be > talking about this. > > > Take Australia for example, I downloaded the entire file of allocated > > numbers from the regulator a while back and ran a script across it. > > Doesn't surprise me. Now do the same trick for Austria and Germany. > > In the .au case, your sole data-source is the NRA. If that would hold > everwhere, then Brian's proposal could work: these numbering-plans > could be easily aggregated into a single database. (Why the hell you > want to do something BGP like for that, I just can't grasp.) > > The trouble, and the reason for the send-n proposal, is the fact that > the NRA of .uk does NOT know the number lengths for all numbers in its > country-code. The same holds for .at, .de and probably a few more. > > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 09:40:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74203A6AA0; Tue, 8 Jul 2008 09:40:52 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FE43A6AA0 for ; Tue, 8 Jul 2008 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk2S+8w8ywvO for ; Tue, 8 Jul 2008 09:40:50 -0700 (PDT) Received: from mail180.messagelabs.com (mail180.messagelabs.com [85.158.139.51]) by core3.amsl.com (Postfix) with SMTP id C29BA3A686C for ; Tue, 8 Jul 2008 09:40:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-5.tower-180.messagelabs.com!1215535258!19126685!1 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.97] Received: (qmail 30891 invoked from network); 8 Jul 2008 16:40:58 -0000 Received: from unknown (HELO GBCWSWIEC002.ad.plc.cwintra.com) (213.216.141.97) by server-5.tower-180.messagelabs.com with SMTP; 8 Jul 2008 16:40:58 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jul 2008 17:40:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 17:40:57 +0100 Message-ID: In-Reply-To: <487371FE.2060608@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: AcjhApNSHXNFLCQyTDGYlmCuiXCwYwAFHJNQ From: "Rosbotham, Paul" To: "Duane" X-OriginalArrivalTime: 08 Jul 2008 16:40:58.0425 (UTC) FILETIME=[6625E290:01C8E119] Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org ok, I'll attempt to decode for you (although the need to do this highlights the need for some kind of system, be that SEND-N or something else) : S1_Code : the field "Number Length" is of the form X+Y, where X = national destination code (area code) and Y is local number. So 0+10 means 10 digit NSN with no area code, 4+6 means 4 digit area code with 6 digit local number etc etc S3_Code : in principle the "Number Length" field would report the number length, but since for 03 numbers they're uniform 10 digits, it hasn't been populated. S5_Code : the "Notes" field contains the number length S7_Code : as S5 S8_Code : as S5. Note that the 0500 range is contained within S8 rather than S5 because it is a historic code that falls within the definition of 08 (ie 0500 is legacy freephone, and nowadays all new freephone is within 080). Note also that there is a significant amount of churn in this file so whatever analysis you do now will be outdated within days/weeks. In brief, whenever a range marked as "Allocated(Closed)" - which will always be 9 digit numbers - becomes totally clear, it is re-allocated as a 10 digit number range (obviously with 10x as many numbers). The frequency of this is unpredictable as it's driven by customer behaviour. S9_Code : as S5. I note that both S8 and S9 have rows with no entry in the Notes field. I would assume that these are 10 digits long, but this is an assumption. Perhaps this re-inforces that getting the data is a non-trivial activity? Although we've used the UK as an example, my experience is that the majority of countries' numbering plans present such difficulties when attempting to decode, and because as an originating carrier we need to provide any-any connectivity globally, we're forced into the position of having to attempt to do that. Each time we get it wrong, we either lose $$$s due to calls being unable to complete, or present a lousy customer experience via post dial delay. Regards Paul -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Duane Sent: 08 July 2008 14:56 To: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues Ray.Bellis@nominet.org.uk wrote: >> Do you have a URI or data set I can run a script over? > > It's all at > http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/ Length is one of the fields in both the excel files and CSV files but doesn't seem to be in any rows, you said the regulators has a fair idea of this information, do they publish it at all? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 09:44:07 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E446C28C1AB; Tue, 8 Jul 2008 09:44:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AE928C1AF for ; Tue, 8 Jul 2008 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fUFI7ldYpZv for ; Tue, 8 Jul 2008 09:44:06 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B34C728C1AA for ; Tue, 8 Jul 2008 09:44:05 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=ak5VOsTH554fcLy1DBZ25x3dzmXKmFn2HeYoMxmwpSzIMJkJu5fv5buX IUgKut4q6tF35inw4d8aXCHNa14u/Y+fr2QpfzzMeTPgYcVDwQWt4U+Cs aFYtqFKNN3iTQwB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215535455; x=1247071455; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-n,=20=20rat=20holes=20and=20real=20issues|Date: =20Tue,=208=20Jul=202008=2017:44:13=20+0100|Message-ID: =20|To:=20enum@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<009101c8e114$e7737c40$1bd213ac@cis.ne ustar.com>|References:=20<02dc01c8dd22$0 e684480$e76af444@cis.neustar.com><03e001 c8dd69$0b950800$e76af444@cis.neustar.com><486DFCE9.9030002@e164.org>=0D=0A=09<20080707074343.GA14 529@nic.at><4872086A.5090602@e164.org>=09<20080707132713. GA15159@nic.at><4872B581.7050702@e164.org>=0D=0A=09<20080 708095449.GA16020@nic.at>=20<009101c8e114$e7737c40$1bd213 ac@cis.neustar.com>; bh=IAD+uTEBAa2o2/NKPYI1Dh/xLRmR4Q+7tRKkHDxoqzE=; b=BURVwnBrDiwhMyzBdltDy/Xxon0KyWJ5nqEait9gzulU2Y3XZ8+L9aBU 88MIIWcLtt/OvX+eKSg4M+R3K83r5OsqtG6P0LZMrWuXWdZd/ef+tLmxE jMOZ249QIQBlocZ; X-IronPort-AV: E=Sophos;i="4.30,324,1212361200"; d="scan'208";a="3986665" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 08 Jul 2008 17:44:14 +0100 In-Reply-To: <009101c8e114$e7737c40$1bd213ac@cis.neustar.com> References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com><03e001c8dd69$0b950800$e76af444@cis.neustar.com><486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at><4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at><4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <009101c8e114$e7737c40$1bd213ac@cis.neustar.com> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 8 Jul 2008 17:44:13 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/07/2008 05:44:14 PM, Serialize complete at 08/07/2008 05:44:14 PM Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > It makes a small database. "Small" is in the current notion of databases. > The kind of database where many of them fit in the disk drive of a US$250 > computer. I can't imagine why any new system could possibly be concerned > about keeping a cache of such a database. Since ENUM and this RR is new, > we're talking about new systems. Brian, You are correct that the data is not "large" in terms of current systems or database capacities. Despite the size, though, it's not static and it's difficult to maintain in every switch in the network. The carriers don't want to do that anymore. See the mails from Paul Rosbotham. He's an expert in the field of maintaining number plan information. IMHO, however, a "routing protocol" type system for distributing such information between devices is immense overkill. It would easily morph into something at least two orders of magnitude more complicated than a DNS-based system, for little additional gain. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 13:34:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462AC28C331; Tue, 8 Jul 2008 13:34:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6286228C330 for ; Tue, 8 Jul 2008 13:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSr1AdvqPgib for ; Tue, 8 Jul 2008 13:34:42 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 862FE28C332 for ; Tue, 8 Jul 2008 13:34:42 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id CC447A6B47; Tue, 8 Jul 2008 21:34:51 +0100 (BST) Message-Id: <3BE4C312-7F33-4697-91E1-E3DB016AA3CA@insensate.co.uk> From: Lawrence Conroy To: Ray.Bellis@nominet.org.uk In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 8 Jul 2008 21:34:51 +0100 References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com><03e001c8dd69$0b950800$e76af444@cis.neustar.com><486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at><4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at><4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <009101c8e114$e7737c40$1bd213ac@cis.neustar.com> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Ray, folks, **Please** don't use the term 'routing protocol' for this data/table distribution. It's bad enough with folk some folk confusing dialing plans and routing plans with number plans, without adding another spanner into the soup. all the best, Lawrence On 8 Jul 2008, at 17:44, Ray.Bellis@nominet.org.uk wrote: > IMHO, however, a "routing protocol" type system for distributing such > information between devices is immense overkill. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 14:32:15 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151533A683A; Tue, 8 Jul 2008 14:32:15 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39A53A683A for ; Tue, 8 Jul 2008 14:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPSG9YyahCec for ; Tue, 8 Jul 2008 14:32:13 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 3CEE83A677E for ; Tue, 8 Jul 2008 14:32:13 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id BADC25AC57E for ; Wed, 9 Jul 2008 07:32:24 +1000 (EST) Message-ID: <4873DCAA.3010000@e164.org> Date: Wed, 09 Jul 2008 07:31:22 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: <02dc01c8dd22$0e684480$e76af444@cis.neustar.com><03e001c8dd69$0b950800$e76af444@cis.neustar.com><486DFCE9.9030002@e164.org> <20080707074343.GA14529@nic.at><4872086A.5090602@e164.org> <20080707132713.GA15159@nic.at><4872B581.7050702@e164.org> <20080708095449.GA16020@nic.at> <009101c8e114$e7737c40$1bd213ac@cis.neustar.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: > into something at least two orders of magnitude more complicated than a > DNS-based system, for little additional gain. So that's the crux of the argument, it's hard so we'll take the easy way out? No, there most certainly is gain, for starters it can be dealt with in a decentralised manner similar to that of BGP, tier-1 providers allow their customers to announce prefix lengths and filter everything else. Where people should stick to a fixed length to minimise the size of the database OR where there is no fixed length some sort of grouping. People are thinking of this from the dialled digits side only but I'm sure there could be a way to group based on the prefix length as well to minimise the data needing to be stored or broadcast or .... Again this is only about prefix lengths not routing information, and is most certainly not a routing protocol. It has a similar benefit as DNS of being decentralised, but every 'node' would have a cached copy of the information so depending on the equipment and the coding, lookup times would be in the sub-ms, which would reduce post dial delay, where as a few DNS server or network or ...... outages could leave people with a bad experience from extended post dial delays. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 14:36:44 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FDE28C36E; Tue, 8 Jul 2008 14:36:44 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3192828C368 for ; Tue, 8 Jul 2008 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTb6rqi3jgl3 for ; Tue, 8 Jul 2008 14:36:42 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 5279728C369 for ; Tue, 8 Jul 2008 14:36:42 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 221565AC57E for ; Wed, 9 Jul 2008 07:36:53 +1000 (EST) Message-ID: <4873DDBA.6070701@e164.org> Date: Wed, 09 Jul 2008 07:35:54 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > ok, I'll attempt to decode for you (although the need to do this highlights the need for some kind of system, be that SEND-N or something else) : No one disagrees about the information being needed in some electronic form automated systems can use, the question is what. I appreciate the time/effort you spent explaining it and will try and parse the CSV info into something usable for this purpose either today or tomorrow depending on what else comes up in the mean time. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 17:31:07 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFF33A6B38; Tue, 8 Jul 2008 17:31:07 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5BB3A6956 for ; Tue, 8 Jul 2008 17:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NwgaZrS0Wlu for ; Tue, 8 Jul 2008 17:31:06 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 2E49B3A69FE for ; Tue, 8 Jul 2008 17:31:05 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m690SaxR003665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Jul 2008 17:29:04 -0700 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Tue, 8 Jul 2008 20:29:56 -0400 Message-ID: <01e001c8e15a$eda0be20$c8e23a60$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjhT6nzTB7DeIIyTbma5s9iOM9k9wACyswQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] FW: 72nd IETF - Final Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat Sent: Tuesday, July 08, 2008 7:10 PM To: IETF Announcement list Cc: irsg@isi.edu; wgchairs@ietf.org; bofchairs@ietf.org Subject: 72nd IETF - Final Agenda 72nd IETF Meeting - Dublin, Ireland July 27-August 1, 2008 Host: Alcatel-Lucent The final agenda has been posted. Please note that changes to the agenda may still occur. You can view the agenda at: https://datatracker.ietf.org/meeting/72/agenda.html There are less than 150 social tickets remaining! You can get more information on the social event and purchase your ticket at: http://ietf72.alcatel-lucent.com/social-1 The Citywest Hotel IETF block booking cutoff is Monday, 14 July. Due to technical problems the hotel is having with their web site reservations system, it is best to either call the hotel directly or send a fax. To call the reservations department directly: +(00) 353 1 401 0418 To send a fax: +(00) 353 1 458 8756 Early-Bird registration cutoff is Friday, 18 July at 17:00 PDT (24:00 UTC/GMT). After that time, the registration fee will increase by $150 USD to $785 USD. Only 19 days until the Dublin IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/72/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 8 21:59:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4299C3A686D; Tue, 8 Jul 2008 21:59:19 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612B33A686D for ; Tue, 8 Jul 2008 21:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-Km07xix59t for ; Tue, 8 Jul 2008 21:59:17 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id A9E273A67A1 for ; Tue, 8 Jul 2008 21:59:16 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m694xN00016165Wed, 9 Jul 2008 04:59:23 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KGRlz-000KB4-00; Wed, 09 Jul 2008 05:59:23 +0100 Date: Wed, 9 Jul 2008 05:59:23 +0100 From: "Clive D.W. Feather" To: "Rosbotham, Paul" Message-ID: <20080709045923.GB77143@finch-staff-1.thus.net> References: <487371FE.2060608@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: enum@ietf.org, Duane Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul said: > S1_Code : the field "Number Length" is of the form X+Y, where X = national destination code (area code) and Y is local number. So 0+10 means 10 digit NSN with no area code, 4+6 means 4 digit area code with 6 digit local number etc etc Note also that "4+6" actually means 12 digits in E.164 form; the three numbers in my .sig are in 2+8, 3+7, and 4+6 form respectively. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 9 00:30:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EB53A69FE; Wed, 9 Jul 2008 00:30:04 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B0ED33A689F; Wed, 9 Jul 2008 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080709073001.B0ED33A689F@core3.amsl.com> Date: Wed, 9 Jul 2008 00:30:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-softswitch-req-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Operational Requirements for ENUM-Based Softswitch Use Author(s) : J. Lim, et al. Filename : draft-ietf-enum-softswitch-req-04.txt Pages : 19 Date : 2008-07-09 This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-softswitch-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-09002902.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Jul 9 00:37:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30A53A68B2; Wed, 9 Jul 2008 00:37:30 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D82D3A67D8; Wed, 9 Jul 2008 00:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X7loSEmcqTj; Wed, 9 Jul 2008 00:37:28 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id EF1FA3A68B1; Wed, 9 Jul 2008 00:37:27 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 03D09A6C9A; Wed, 9 Jul 2008 08:37:38 +0100 (BST) Message-Id: <3BC31888-B7E8-4FC5-91B5-C6CD02973AE9@insensate.co.uk> From: Lawrence Conroy To: internet-drafts@ietf.org In-Reply-To: <20080709073001.B0ED33A689F@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 08:37:38 +0100 References: <20080709073001.B0ED33A689F@core3.amsl.com> X-Mailer: Apple Mail (2.926) Cc: IETF ENUM WG Subject: Re: [Enum] I-D Action:draft-ietf-enum-softswitch-req-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, this version of the softswitch draft was produced to reflect SECDIR report and IESG discuss points. We're done on this one (I hope :). all the best, Lawrence On 9 Jul 2008, at 08:30, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Telephone Number Mapping Working > Group of the IETF. > > > Title : Operational Requirements for ENUM-Based > Softswitch Use > Author(s) : J. Lim, et al. > Filename : draft-ietf-enum-softswitch-req-04.txt > Pages : 19 > Date : 2008-07-09 > > This document describes experiences of operational requirements and > several considerations for ENUM-based softswitches concerning call > routing between two Korean VoIP carriers, gained during the ENUM pre- > commercial trial hosted by National Internet Development Agency of > Korea (NIDA) in 2006. > > These experiences show that an interim solution can maintain the > stability of on-going commercial softswitch system operations during > the initial stage of ENUM service, where the DNS does not have > sufficient data for the majority of calls. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 04:28:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1813A69E0; Thu, 10 Jul 2008 04:28:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1AA63A69E0 for ; Thu, 10 Jul 2008 04:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dqpLd03-cfe for ; Thu, 10 Jul 2008 04:28:30 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id DF1563A68D0 for ; Thu, 10 Jul 2008 04:28:30 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A26765AC57E for ; Thu, 10 Jul 2008 21:28:43 +1000 (EST) Message-ID: <4875F21E.3020609@e164.org> Date: Thu, 10 Jul 2008 21:27:26 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > I note that both S8 and S9 have rows with no entry in the Notes > field. I would assume that these are 10 digits long, but this is an > assumption. Perhaps this re-inforces that getting the data is a > non-trivial activity? Actually S7 doesn't either. Does anyone have a better/more accurate source of information? Based on the information at hand most routes seems to be 10 digits except for S8 which has 9 and 7 digit numbers listed as well. If the missing information means 10 digits it would be pretty trivial to collate this information, however that would be guessing and someone should have this information published somewhere especially if someone is planning to put it into send-n, or is the information going into send-n guesses too? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 04:41:17 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623053A69CD; Thu, 10 Jul 2008 04:41:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0493A695B for ; Thu, 10 Jul 2008 04:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZQoZrzSi7tx for ; Thu, 10 Jul 2008 04:41:14 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 9E5183A6932 for ; Thu, 10 Jul 2008 04:41:14 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=KQznNqzfmTyKypxWKidnFim7bl2+C5fdQyJXXPEkPxX30deUxa7hqY/O 7umbLUwmkKKTqN2xYsD3Ui/wSdFu+RboQkVn1v+lF0mv+LMqMXfHb3IM8 J+ux8Pno7LrjKiQ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1215690089; x=1247226089; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-n,=20=20rat=20holes=20and=20real=20issues|Date: =20Thu,=2010=20Jul=202008=2012:41:27=20+0100|Message-ID: =20|To:=20enum@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<4875F21E.3020609@e164.org> |References:=20=20<4875F21E.3020609@e164.o rg>; bh=3HbGZSl1FCly5Yh9qRx+VT/zW7Z74v1l2voZ8I7d6AE=; b=BKQYgz1o6ArQ24f802rOnfV/y3U9M0Jw3iiwigIAYmJfnDpuezrkpxlv bc3x/6EMCfL5/h5VrPG47sQhXTtHIOqujaxuHLXK1Znh9nx8kwc7N2nas sFuJwFVuT2FzfGj; X-IronPort-AV: E=Sophos;i="4.30,338,1212361200"; d="scan'208";a="4026103" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 10 Jul 2008 12:41:27 +0100 In-Reply-To: <4875F21E.3020609@e164.org> References: <4875F21E.3020609@e164.org> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 10 Jul 2008 12:41:27 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 10/07/2008 12:41:27 PM, Serialize complete at 10/07/2008 12:41:27 PM Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > If the missing information means 10 digits it would be pretty trivial to > collate this information, however that would be guessing and someone > should have this information published somewhere especially if someone > is planning to put it into send-n, or is the information going into > send-n guesses too? For the UK the send-n information will be derived from the contents of the central numbering database. The addition of any range of numbers to the database will require authorisation of the regulator. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 04:45:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5033A6932; Thu, 10 Jul 2008 04:45:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058DE3A6932 for ; Thu, 10 Jul 2008 04:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd4+plDhdqqh for ; Thu, 10 Jul 2008 04:45:06 -0700 (PDT) Received: from mail177.messagelabs.com (mail177.messagelabs.com [85.158.138.99]) by core3.amsl.com (Postfix) with SMTP id 94FF928C0DF for ; Thu, 10 Jul 2008 04:45:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-13.tower-177.messagelabs.com!1215690315!9615898!4 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 26230 invoked from network); 10 Jul 2008 11:45:18 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-13.tower-177.messagelabs.com with SMTP; 10 Jul 2008 11:45:18 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 12:45:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 12:43:37 +0100 Message-ID: In-Reply-To: <4875F21E.3020609@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: AcjigCG3Vpt839lPQ0+ho3L7YT3UhAAAe4VQ From: "Rosbotham, Paul" To: "Duane" , X-OriginalArrivalTime: 10 Jul 2008 11:45:15.0511 (UTC) FILETIME=[6B5F9070:01C8E282] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org LOL, you're learning. I went through similar angst trying to prepare the NICC number length guidelines document I referenced earlier in this thread. I think you missed that there are a couple of hundred assorted ranges in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8 digits. Also, specific ranges in S=8 (ie +44 8) which are 7 digit (e.g. (0)800 1111 is our child helpine). NB as Clive said, when I say 9, that's 11 in international form (inc 44). What you're looking at is the supposedly authoritative source of data. Better info can be found, but only by talking to the individual CPs...of which there are currently 384, off the top of my head. That's what we're trying to get away from. The point of Send-N is that the records are set according to what's populated into ENUM. - In the context of our porting database (ie a private ENUM), current plans are that it would be populated with all numbers hence Send-N would reflect the true structure of the numbering plan. - In the context of user-ENUM where population is inevitably partial, then Send-N would reflect what's in there...e.g. if +448001111 wasn't populated, then no Send-N records would reflect its existence. That's the point that Jay's been trying to get across...in a user-ENUM context the number lengths as specified by the numbering plan administrator are of limited value...e.g. if there was a range in the UK that was 15 digits long, coding that into Send-N in ENUM is pretty pointless unless any such numbers were actually populated in ENUM. Cheers Paul -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Duane Sent: 10 July 2008 12:27 To: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues Rosbotham, Paul wrote: > I note that both S8 and S9 have rows with no entry in the Notes > field. I would assume that these are 10 digits long, but this is an > assumption. Perhaps this re-inforces that getting the data is a > non-trivial activity? Actually S7 doesn't either. Does anyone have a better/more accurate source of information? Based on the information at hand most routes seems to be 10 digits except for S8 which has 9 and 7 digit numbers listed as well. If the missing information means 10 digits it would be pretty trivial to collate this information, however that would be guessing and someone should have this information published somewhere especially if someone is planning to put it into send-n, or is the information going into send-n guesses too? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 05:08:41 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2003A3A6A04; Thu, 10 Jul 2008 05:08:41 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121B43A69FD for ; Thu, 10 Jul 2008 05:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZoUpqtGdsO8 for ; Thu, 10 Jul 2008 05:08:39 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 3FA3C3A6990 for ; Thu, 10 Jul 2008 05:08:39 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 79E83FF270 for ; Thu, 10 Jul 2008 22:08:53 +1000 (EST) Message-ID: <4875FB88.4060603@e164.org> Date: Thu, 10 Jul 2008 22:07:36 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > LOL, you're learning. I went through similar angst trying to prepare the NICC number length guidelines document I referenced earlier in this thread. > > I think you missed that there are a couple of hundred assorted ranges in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8 digits. Also, specific ranges in S=8 (ie +44 8) which are 7 digit (e.g. (0)800 1111 is our child helpine). NB as Clive said, when I say 9, that's 11 in international form (inc 44). > > What you're looking at is the supposedly authoritative source of data. Better info can be found, but only by talking to the individual CPs...of which there are currently 384, off the top of my head. That's what we're trying to get away from. > > The point of Send-N is that the records are set according to what's populated into ENUM. > > - In the context of our porting database (ie a private ENUM), current plans are that it would be populated with all numbers hence Send-N would reflect the true structure of the numbering plan. > - In the context of user-ENUM where population is inevitably partial, then Send-N would reflect what's in there...e.g. if +448001111 wasn't populated, then no Send-N records would reflect its existence. That's the point that Jay's been trying to get across...in a user-ENUM context the number lengths as specified by the numbering plan administrator are of limited value...e.g. if there was a range in the UK that was 15 digits long, coding that into Send-N in ENUM is pretty pointless unless any such numbers were actually populated in ENUM. That is the most pointless thing I have ever heard of. I think we're all agreed this information would be good if it were to be made available in a useful form, now you're saying the information will only be partially available if there is a NAPTR record, but if one or more NAPTR records exist for a end user record then there is no need for send-n, what the ???? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 05:10:23 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5203A69FD; Thu, 10 Jul 2008 05:10:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B6B3A6990 for ; Thu, 10 Jul 2008 05:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjlpLnepRNhX for ; Thu, 10 Jul 2008 05:10:21 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 546A83A6A04 for ; Thu, 10 Jul 2008 05:10:21 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 04F9EFF270 for ; Thu, 10 Jul 2008 22:10:35 +1000 (EST) Message-ID: <4875FBEF.1000806@e164.org> Date: Thu, 10 Jul 2008 22:09:19 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <4875F21E.3020609@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: > For the UK the send-n information will be derived from the contents of the > central numbering database. > > The addition of any range of numbers to the database will require > authorisation of the regulator. So the answer is no one has any idea of what a complete picture of the UK dial plan current looks like? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 05:20:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D657428C0E6; Thu, 10 Jul 2008 05:20:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A9128C0E5 for ; Thu, 10 Jul 2008 05:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK4Vn7pYd-6F for ; Thu, 10 Jul 2008 05:20:24 -0700 (PDT) Received: from mail90.messagelabs.com (mail90.messagelabs.com [85.158.139.3]) by core3.amsl.com (Postfix) with SMTP id 7E73928C0E4 for ; Thu, 10 Jul 2008 05:20:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-4.tower-90.messagelabs.com!1215692405!37519821!19 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.97] Received: (qmail 7786 invoked from network); 10 Jul 2008 12:20:28 -0000 Received: from unknown (HELO GBCWSWIEC002.ad.plc.cwintra.com) (213.216.141.97) by server-4.tower-90.messagelabs.com with SMTP; 10 Jul 2008 12:20:28 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 13:20:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 13:19:43 +0100 Message-ID: In-Reply-To: <4875FB88.4060603@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: Acjihbw2g40rwYT4RkCfkqcuzQ5JaAAAJ6mg From: "Rosbotham, Paul" To: "Duane" , X-OriginalArrivalTime: 10 Jul 2008 12:20:22.0187 (UTC) FILETIME=[530CCFB0:01C8E287] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > - In the context of user-ENUM where population is > inevitably partial, then Send-N would reflect what's in > there...e.g. if +448001111 wasn't populated, then no Send-N > records would reflect its existence. That's the point that > Jay's been trying to get across...in a user-ENUM context the > number lengths as specified by the numbering plan > administrator are of limited value...e.g. if there was a > range in the UK that was 15 digits long, coding that into > Send-N in ENUM is pretty pointless unless any such numbers > were actually populated in ENUM. > > That is the most pointless thing I have ever heard of. > > I think we're all agreed this information would be good if it > were to be > made available in a useful form, now you're saying the > information will > only be partially available if there is a NAPTR record, but if one or > more NAPTR records exist for a end user record then there is > no need for > send-n, what the ???? > No, the other way around. Let's say that +448001111 *is* populated with it's NAPTRs. In that case, a query to 0.0.8.4.4.e164.foo would return a send-N with (assuming absolute) N = 9. If, however, +448001111 was not populated, that would mean that all of the numbers actually in ENUM behind +44800 would be of either 11 or 12 digits long. In that case, a query to 0.0.8.4.4.e164.foo would return a send-N with (assuming absolute) N = 11. ...the point is the Send-N records are populated according to what NAPTRs *are* populated, not according to those which could theoretically be populated. In the latter example, it's saying "don't bother querying me until you've got at least 11 digits because there's nothing in ENUM with anything less". It's *not* saying "according to the numbering plan administrator, all numbers in this range are at least 11 digits long". Subtle difference. This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 05:24:50 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68623A6A32; Thu, 10 Jul 2008 05:24:50 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2138F3A6A32 for ; Thu, 10 Jul 2008 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TfKUYWDse+o for ; Thu, 10 Jul 2008 05:24:48 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 587D73A6A06 for ; Thu, 10 Jul 2008 05:24:48 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E3B6AFF270 for ; Thu, 10 Jul 2008 22:25:02 +1000 (EST) Message-ID: <4875FF51.6050909@e164.org> Date: Thu, 10 Jul 2008 22:23:45 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > ...the point is the Send-N records are populated according to what NAPTRs *are* populated, not according to those which could theoretically be populated. In the latter example, it's saying "don't bother querying me until you've got at least 11 digits because there's nothing in ENUM with anything less". It's *not* saying "according to the numbering plan administrator, all numbers in this range are at least 11 digits long". Subtle difference. That was my point, if there is NAPTR records present you want to supplement it with a send-n, but what's the point in that since the NAPTR record would be present anyway. This is gone from wanting to know what prefix lengths are to wanting to know when a NAPTR is present by having a second one for good measure. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 06:07:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6783A6995; Thu, 10 Jul 2008 06:07:20 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89903A6995 for ; Thu, 10 Jul 2008 06:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7ePyR9VC6gd for ; Thu, 10 Jul 2008 06:07:18 -0700 (PDT) Received: from mail150.messagelabs.com (mail150.messagelabs.com [85.158.136.115]) by core3.amsl.com (Postfix) with SMTP id 469FE3A688A for ; Thu, 10 Jul 2008 06:07:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-8.tower-150.messagelabs.com!1215695236!9265658!4 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.97] Received: (qmail 10835 invoked from network); 10 Jul 2008 13:07:25 -0000 Received: from unknown (HELO GBCWSWIEC002.ad.plc.cwintra.com) (213.216.141.97) by server-8.tower-150.messagelabs.com with SMTP; 10 Jul 2008 13:07:25 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 14:07:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 14:05:25 +0100 Message-ID: In-Reply-To: <4875FF51.6050909@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: Acjih/2n1f64ZYwoSo6eaVAuAY5vJwAA5hDg From: "Rosbotham, Paul" To: "Duane" , X-OriginalArrivalTime: 10 Jul 2008 13:07:17.0161 (UTC) FILETIME=[E0E7C190:01C8E28D] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > > Rosbotham, Paul wrote: > > > ...the point is the Send-N records are populated according > to what NAPTRs *are* populated, not according to those which > could theoretically be populated. In the latter example, > it's saying "don't bother querying me until you've got at > least 11 digits because there's nothing in ENUM with anything > less". It's *not* saying "according to the numbering plan > administrator, all numbers in this range are at least 11 > digits long". Subtle difference. > > That was my point, if there is NAPTR records present you want to > supplement it with a send-n, but what's the point in that since the > NAPTR record would be present anyway. > > This is gone from wanting to know what prefix lengths are to > wanting to > know when a NAPTR is present by having a second one for good measure. > Ok, I'll try one more time. Let's say for the sake of argument that +448001111 isn't present, end-user is dialling : ultimately they're going to dial 0800123456 but so far they've only dialled 0800 and are dithering about what the next digit is. If I query on 0.0.8.4.4.e164.foo I get a Send-N of 11. In absence of Send-N records I get no information other than there's no NAPTR for that combination of digits. With the Send-11, I know that when the customer dials "1" (recall I already have the 0800) there's no point in requerying. Likewise when they dial 2. In fact, I don't bother requerying until they've dialled 0800123456. The query on 6.5.4.3.2.1.0.0.8.e164.foo provides the NAPTR. It doesn't result in a Send-N. Without the Send-11, with no knowledge of the numbering plan I'd query on 1.0.0.8.e164.foo, then 2.1.0.0.8.e164.foo etc. Now, because there's a mixture of number lengths in +44800, if my user was instead dialing 08001234789 (ie in a range one digit longer), when I queried on the 8.7.4.3.2.1.0.0.8.4.4.e164.foo having collected 11 digits after getting a Send-11, it would result in another Send-N, this time N=12 because the extra information I've provided has pinpointed it to being a number in a longer range. This assumes at least one of x.8.7.4.3.2.1.0.0.8.4.4.e164.foo (x=0...9) is populated...if it's not it's pointless me collecting an extra digit and requerying, because I'll still get no record for my query. So, for numbering plans where no complete number is a prefix of another (*), you should either get the NAPTR per today, or a Send-N, but not both. (*) I believe that in some countries that may not be the case, e.g. 01234567 and 01234567890 can exist as separate numbers...obviously there'd be issues in that scenario. This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 06:28:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975BD3A68F4; Thu, 10 Jul 2008 06:28:12 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7AC3A68F4 for ; Thu, 10 Jul 2008 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ8rSbDPb4QB for ; Thu, 10 Jul 2008 06:28:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id DC3B53A6827 for ; Thu, 10 Jul 2008 06:28:10 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KGwC5-00080a-45; Thu, 10 Jul 2008 08:28:21 -0500 From: "Brian Rosen" To: "'Rosbotham, Paul'" , "'Duane'" , References: <4875F21E.3020609@e164.org> Date: Thu, 10 Jul 2008 09:28:21 -0400 Message-ID: <03c801c8e290$d49aec70$1bd213ac@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjigCG3Vpt839lPQ0+ho3L7YT3UhAAAe4VQAAOL1oA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > What you're looking at is the supposedly authoritative source of data. > Better info can be found, but only by talking to the individual CPs...of > which there are currently 384, off the top of my head. That's what we're > trying to get away from. > > The point of Send-N is that the records are set according to what's > populated into ENUM. And how does the ENUM operator get the data? It needs to get data from 384 CPs, plus the regulator, right? If the ENUM database was a world-wide database, it has to get the data from thousands of sources in different countries, right? Doesn't that imply some sort of standardization? And then, having standardized a way to get the data, why is that not good enough for everyone? _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 07:01:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05DA3A698B; Thu, 10 Jul 2008 07:01:48 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F003A698B for ; Thu, 10 Jul 2008 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSiaVlkjj1qf for ; Thu, 10 Jul 2008 07:01:47 -0700 (PDT) Received: from mail180.messagelabs.com (mail180.messagelabs.com [85.158.139.51]) by core3.amsl.com (Postfix) with SMTP id 912E43A6918 for ; Thu, 10 Jul 2008 07:01:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-14.tower-180.messagelabs.com!1215698519!19942185!5 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 20945 invoked from network); 10 Jul 2008 14:02:00 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-14.tower-180.messagelabs.com with SMTP; 10 Jul 2008 14:02:00 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 15:01:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 15:01:57 +0100 Message-ID: In-Reply-To: <03c801c8e290$d49aec70$1bd213ac@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: AcjigCG3Vpt839lPQ0+ho3L7YT3UhAAAe4VQAAOL1oAAAOFGUA== From: "Rosbotham, Paul" To: "Brian Rosen" , X-OriginalArrivalTime: 10 Jul 2008 14:01:58.0769 (UTC) FILETIME=[84E56610:01C8E295] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > > What you're looking at is the supposedly authoritative > source of data. > > Better info can be found, but only by talking to the > individual CPs...of > > which there are currently 384, off the top of my head. > That's what we're > > trying to get away from. > > > > The point of Send-N is that the records are set according to what's > > populated into ENUM. > And how does the ENUM operator get the data? It needs to get > data from 384 > CPs, plus the regulator, right? If the ENUM database was a world-wide > database, it has to get the data from thousands of sources in > different > countries, right? > > Doesn't that imply some sort of standardization? > > And then, having standardized a way to get the data, why is > that not good > enough for everyone? > Who is "the ENUM operator" in this context? My view, in a user-ENUM environment you're talking about the T1 registry for a given country. When a number's registered today, the Tier 2 has to notify the Tier 1 to make the delegation, as well as populating the NAPTRs on their DNS server. Add Send-N to the mix, and the Tier 1 also has the task of synthesizing the Send-Ns based upon the info received for that and previous delegations. As to whether the T1 is prepared to do that...well I can only say that the author of the I-D is the UK T1. If a country had no need for Send-N (e.g. fixed length plan), then I haven't seen anything in Ray's proposals that mandates Send-Ns be populated. Of course, if there's a desire to come up with something which meets the requirements of Send-N using something other than ENUM so couldn't leverage existing standards, then there would be a need for new stuff. As an aside, in the UK portability context, the CDB provider will synthesize Send-Ns according to information populated by the CPs about active numbers. The management interface has been standardised for providing that information. I can't go into any detail about the level of support for this by CDB vendors because we're subject to EU Public Procurement legislation at present, but suffice to say that our prospective providers are not flagging support of this as an issue. This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 13:54:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02333A6929; Thu, 10 Jul 2008 13:54:47 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B773A6929 for ; Thu, 10 Jul 2008 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTTzHiMP2N3Y for ; Thu, 10 Jul 2008 13:54:45 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 8B3833A680F for ; Thu, 10 Jul 2008 13:54:45 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 85649FF270 for ; Fri, 11 Jul 2008 06:55:02 +1000 (EST) Message-ID: <487676D1.1010001@e164.org> Date: Fri, 11 Jul 2008 06:53:37 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > So, for numbering plans where no complete number is a prefix of another (*), you should either get the NAPTR per today, or a Send-N, but not both. I can't help but think this doesn't belong in DNS, repeating hit after hit on name servers when the information could be dealt with at a local level has to be the better way to do it surely. > (*) I believe that in some countries that may not be the case, e.g. 01234567 and 01234567890 can exist as separate numbers...obviously there'd be issues in that scenario. I wonder if this made it into the send-n proposal, in any case this highlights further the need for a proper think about how to do this rather than going bull at a gate with something that sort of works but seems like a very nasty hack to me. There seems to be a lot of effort to 'fix' the analogue problem, the simple answer would be to move everyone to digital systems and when they hit dial that's the final number :D -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 10 14:19:36 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241653A6A75; Thu, 10 Jul 2008 14:19:36 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22E93A6A8A for ; Thu, 10 Jul 2008 14:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFqiYTQw2NAx for ; Thu, 10 Jul 2008 14:19:33 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 4295E3A6929 for ; Thu, 10 Jul 2008 14:19:32 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6ALF7XU029824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2008 14:15:23 -0700 From: "Richard Shockey" To: "'Rosbotham, Paul'" , "'Duane'" , References: <4875F21E.3020609@e164.org> In-Reply-To: Date: Thu, 10 Jul 2008 17:15:46 -0400 Message-ID: <113901c8e2d2$3ad1b2d0$b0751870$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjigCG3Vpt839lPQ0+ho3L7YT3UhAAAe4VQABPrOuA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org So why doesn't someone go to Gordon Brown and tell him to fix the bloody UK dial plan? Oh ..that's right they tried that before and a couple of Ministers got sacked. And with the latest poll numbers looking as they do ...probably not a real option. :-) Sorry ... > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Rosbotham, Paul > Sent: Thursday, July 10, 2008 7:44 AM > To: Duane; enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > LOL, you're learning. I went through similar angst trying to prepare > the NICC number length guidelines document I referenced earlier in > this thread. > > I think you missed that there are a couple of hundred assorted ranges > in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8 > digits. Also, specific ranges in S=8 (ie +44 8) which are 7 digit > (e.g. (0)800 1111 is our child helpine). NB as Clive said, when I say > 9, that's 11 in international form (inc 44). > > What you're looking at is the supposedly authoritative source of data. > Better info can be found, but only by talking to the individual > CPs...of which there are currently 384, off the top of my head. > That's what we're trying to get away from. > > The point of Send-N is that the records are set according to what's > populated into ENUM. > > - In the context of our porting database (ie a private ENUM), current > plans are that it would be populated with all numbers hence Send-N > would reflect the true structure of the numbering plan. > - In the context of user-ENUM where population is inevitably partial, > then Send-N would reflect what's in there...e.g. if +448001111 wasn't > populated, then no Send-N records would reflect its existence. That's > the point that Jay's been trying to get across...in a user-ENUM > context the number lengths as specified by the numbering plan > administrator are of limited value...e.g. if there was a range in the > UK that was 15 digits long, coding that into Send-N in ENUM is pretty > pointless unless any such numbers were actually populated in ENUM. > > Cheers > > Paul > > > > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of > Duane > Sent: 10 July 2008 12:27 > To: enum@ietf.org > Subject: Re: [Enum] Send-n, rat holes and real issues > > > Rosbotham, Paul wrote: > > > I note that both S8 and S9 have rows with no entry in the Notes > > field. I would assume that these are 10 digits long, but this is an > > assumption. Perhaps this re-inforces that getting the data is a > > non-trivial activity? > > Actually S7 doesn't either. Does anyone have a better/more accurate > source of information? > > Based on the information at hand most routes seems to be 10 digits > except for S8 which has 9 and 7 digit numbers listed as well. > > If the missing information means 10 digits it would be pretty trivial > to > collate this information, however that would be guessing and someone > should have this information published somewhere especially if someone > is planning to put it into send-n, or is the information going into > send-n guesses too? > > -- > > Best regards, > Duane > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > > This e-mail has been scanned for viruses by the Cable & Wireless e- > mail security system - powered by MessageLabs. For more information on > a proactive managed e-mail security service, visit > http://www.cw.com/uk/emailprotection/ > > The information contained in this e-mail is confidential and may also > be subject to legal privilege. It is intended only for the > recipient(s) named above. If you are not named above as a recipient, > you must not read, copy, disclose, forward or otherwise use the > information contained in this email. If you have received this e-mail > in error, please notify the sender (whose contact details are above) > immediately by reply e-mail and delete the message and any attachments > without retaining any copies. > > Cable and Wireless plc > Registered in England and Wales.Company Number 238525 > Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 01:00:00 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ECB3A6B0C; Fri, 11 Jul 2008 01:00:00 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BA528C126 for ; Fri, 11 Jul 2008 00:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAxh5r89PQCm for ; Fri, 11 Jul 2008 00:59:58 -0700 (PDT) Received: from mail140.messagelabs.com (mail140.messagelabs.com [85.158.137.83]) by core3.amsl.com (Postfix) with SMTP id 722513A6AF7 for ; Fri, 11 Jul 2008 00:59:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-8.tower-140.messagelabs.com!1215763214!12763160!1 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.97] Received: (qmail 24464 invoked from network); 11 Jul 2008 08:00:14 -0000 Received: from unknown (HELO GBCWSWIEC002.ad.plc.cwintra.com) (213.216.141.97) by server-8.tower-140.messagelabs.com with SMTP; 11 Jul 2008 08:00:14 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 09:00:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 09:00:13 +0100 Message-ID: In-Reply-To: <113901c8e2d2$3ad1b2d0$b0751870$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: AcjigCG3Vpt839lPQ0+ho3L7YT3UhAAAe4VQABPrOuAAFkbccA== From: "Rosbotham, Paul" To: "Richard Shockey" , "Duane" , X-OriginalArrivalTime: 11 Jul 2008 08:00:14.0358 (UTC) FILETIME=[2678DB60:01C8E32C] Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: 10 July 2008 22:16 > > > So why doesn't someone go to Gordon Brown and tell him to fix > the bloody UK > dial plan? > > Oh ..that's right they tried that before and a couple of Ministers got > sacked. > > And with the latest poll numbers looking as they do > ...probably not a real > option. :-) > > Sorry ... Tell you what, I'll do that when you tell George Dubya to forceably migrate everyone onto IPv6 ;-) Seriously, though, getting a fixed length plan is a non-option. The main fragmented range is 08. That's because there's a mixture of legacy 0800+6 digit numbers, and newer 0800+7 digit numbers. The industry tried to move to a uniform plan in this area a few years ago, and there was blood on the floor by the end. You've got to recognise that large corporates have dedicated considerable advertising spend to building brands around their numbers, and they don't like to change. Think in terms of the reaction if you went out and told every 800 number-holder in the US that they'd need to change their number... There is a risk of this being characterised as a uniquely UK issue, though, which is not the case. It's just we've got the biggest mouths. Off the top of my head, similar issues would arise with complex variable length plans in Australia, Bangladesh, Belgium, China, Germany, Greece, India, Ireland, Italy, Monaco, Netherlands, Nigera, Pakistan, Poland, Portugal, Russia, South Africa, Spain, Sweden, Switzerland... (this is using the criterion that it would take more than 50 lines to summarise the number lengths in the plan) This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 02:00:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0128C28C13F; Fri, 11 Jul 2008 02:00:02 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87BD28C155 for ; Fri, 11 Jul 2008 02:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imvRwugaD7gp for ; Fri, 11 Jul 2008 01:59:59 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 8FF6428C13F for ; Fri, 11 Jul 2008 01:59:59 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E09E0FF27F for ; Fri, 11 Jul 2008 19:00:19 +1000 (EST) Message-ID: <487720C9.6020508@e164.org> Date: Fri, 11 Jul 2008 18:58:49 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Rosbotham, Paul wrote: > Tell you what, I'll do that when you tell George Dubya to forceably migrate everyone onto IPv6 ;-) Actually they did (sort of) all US govt backbones had a dead line of June 30th to support IPv6 and to everyone's surprise apparently it happened. > Seriously, though, getting a fixed length plan is a non-option. The main fragmented range is 08. That's because there's a mixture of legacy 0800+6 digit numbers, and newer 0800+7 digit numbers. The industry tried to move to a uniform plan in this area a few years ago, and there was blood on the floor by the end. You've got to recognise that large corporates have dedicated considerable advertising spend to building brands around their numbers, and they don't like to change. Think in terms of the reaction if you went out and told every 800 number-holder in the US that they'd need to change their number... Australia did this between 1995 and 1999 I think it was completed, companies used to have 008 numbers but were forcibly moved to (+61)1800 along with all the other dial plan changes like 0055 numbers moving to (+61)1900 and virtually every area code merging with all the other area codes in the same state if not multiple states. > There is a risk of this being characterised as a uniquely UK issue, though, which is not the case. It's just we've got the biggest mouths. Off the top of my head, similar issues would arise with complex variable length plans in Australia, Bangladesh, Belgium, China, Germany, Greece, India, Ireland, Italy, Monaco, Netherlands, Nigera, Pakistan, Poland, Portugal, Russia, South Africa, Spain, Sweden, Switzerland... (this is using the criterion that it would take more than 50 lines to summarise the number lengths in the plan) While you may be technically correct about needing more than 50 lines to describe the dial plan for Australia, the majority of people and for most routes that can be dialled internationally to Australia can be summarised in a lot less than 50. For the most part this is all that anyone needs: 61[2378]NXXXXXXX - Geographical numbers 614XXXXXXXX - Mobile numbers 61130XXXXXXX - Caller and Callee pays 6113ZXXX - Caller and Callee pays 611345XXXX - Security systems, shouldn't be needed for international calls ever 61180[01]XXXXXX - toll free 61180NXXX - govt toll free 61190[0126]XXXXXX - premium rate voice services 6119[1345]XXX - premium rate SMS services 6119[679]XXXXX - premium rate SMS services Actually out of the above list the main numbers called by people are geo, mobile and 13/18 numbers, although I'm sure there is a lot of calls/sms to 19 numbers based on all the ads on tv for different services. However most VoIP/VSP companies won't touch 19 numbers because of the difficulty in billing services. While there is 82 routes listed on http://www.e164.org/wiki/AU_Dialplan a lot of these numbers can't be called/used outside of Australia, eg 000 is emergency services (like 911 or 112 etc), 001X and 14XX override prefixes for local, long distance, mobile and international calls, 019 numbers are charged at local rates but are data services for ISPs usually, majority of the geographical route information could be summarised instead of the way I have it fleshed out, I went through and pulled out all the information about allocated numbers and that list was correct a few months ago. The 12X numbers are 'special' numbers like directory services and other carrier things, and hardly any numbers in the +615. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 02:24:56 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19CA3A6ADA; Fri, 11 Jul 2008 02:24:56 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C753A6ADA for ; Fri, 11 Jul 2008 02:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f3KfSsaSJAH for ; Fri, 11 Jul 2008 02:24:53 -0700 (PDT) Received: from mail93.messagelabs.com (mail93.messagelabs.com [194.106.220.67]) by core3.amsl.com (Postfix) with SMTP id 5C8D53A6AC4 for ; Fri, 11 Jul 2008 02:24:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-15.tower-93.messagelabs.com!1215768265!14626139!41 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 21784 invoked from network); 11 Jul 2008 09:25:07 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-15.tower-93.messagelabs.com with SMTP; 11 Jul 2008 09:25:07 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 10:24:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Jul 2008 10:23:49 +0100 Message-ID: In-Reply-To: <487720C9.6020508@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Send-n, rat holes and real issues Thread-Index: AcjjNI1E4YeoSO/UTdGDL2LCijmHAAAAjHgg From: "Rosbotham, Paul" To: "Duane" X-OriginalArrivalTime: 11 Jul 2008 09:24:47.0800 (UTC) FILETIME=[F67AAB80:01C8E337] Cc: enum@ietf.org Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > While you may be technically correct about needing more than > 50 lines to > describe the dial plan for Australia, the majority of people and for > most routes that can be dialled internationally to Australia can be > summarised in a lot less than 50. For the most part this is all that > anyone needs: > Thanks Duane, your analysis is interesting. HOWEVER as a telephony provider, I don't have the luxury of maintaining data that will cope with the "majority" of calls. I have to cope with all of them hence do need to go to that next level of detail (or use timers...typically for level 0/1 in Australia we do that). This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 03:04:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273313A6A5A; Fri, 11 Jul 2008 03:04:20 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7844C3A6947 for ; Fri, 11 Jul 2008 03:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vABgGs18t+O4 for ; Fri, 11 Jul 2008 03:04:17 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 82ED43A6A5A for ; Fri, 11 Jul 2008 03:04:17 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id D5369FF27F for ; Fri, 11 Jul 2008 20:04:33 +1000 (EST) Message-ID: <48772FDB.90000@e164.org> Date: Fri, 11 Jul 2008 20:03:07 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: enum@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-n, rat holes and real issues X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556899606==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1556899606== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0558D01F3B01E067C1BC0D2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0558D01F3B01E067C1BC0D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rosbotham, Paul wrote: > your analysis is interesting. HOWEVER as a telephony provider, I don't= have the luxury of maintaining data that will cope with the "majority" o= f calls. I have to cope with all of them hence do need to go to that nex= t level of detail (or use timers...typically for level 0/1 in Australia w= e do that). No there is nothing about length so timers wouldn't come into it, the only difference is if the number is allocated or not. --=20 Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Global Communication for the 21st Century "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." --------------enigA0558D01F3B01E067C1BC0D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIdy/bEpWoZMmo/c8RAn9+AKCIQTSoR+BbkMDksXtNJ4cqzvqIGACg171E M0iaOXJze/Q9FX29UpEemoc= =Qxo1 -----END PGP SIGNATURE----- --------------enigA0558D01F3B01E067C1BC0D2-- --===============1556899606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum --===============1556899606==-- From enum-bounces@ietf.org Fri Jul 11 08:07:29 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8890E3A6B34; Fri, 11 Jul 2008 08:07:29 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5D33A6B34 for ; Fri, 11 Jul 2008 08:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE+KjdCj24Up for ; Fri, 11 Jul 2008 08:07:28 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id BE74D3A6B2F for ; Fri, 11 Jul 2008 08:07:27 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6BCrMgl007942Fri, 11 Jul 2008 12:53:24 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KHI1F-0005nb-00; Fri, 11 Jul 2008 13:46:37 +0100 Date: Fri, 11 Jul 2008 13:46:37 +0100 From: "Clive D.W. Feather" To: Pete Cordell Message-ID: <20080711124636.GF20707@finch-staff-1.thus.net> References: <48657FC5.2010205@e164.org> <002f01c8dad6$b9bee0d0$ea00a8c0@Codalogic> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <002f01c8dad6$b9bee0d0$ea00a8c0@Codalogic> User-Agent: Mutt/1.5.3i Cc: enum@ietf.org, Ray.Bellis@nominet.org.uk Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Tidying up along the thread. This isn't a major issue, but ... Pete Cordell said: >>>understood. Since that is an optimization for a provisioning issue of >>>- to me - unclear frequency of occurence, would much be lost with using >>>the absolute value only? >> Personally I'm not sure. Clive thinks relative is useful. > From what I understand of this issue, the relative form of send-n just does > not seem worth the grief. It's already been said that the zone files (or > what ever the preferred DNS input will be) will be automatically generated > by some sort of automated process such as a script. So, pre-number move at > some point a script will be used to generate a set of zone files. When the > new number plan comes along it seems just as easy to re-build a new set of > zones based on the new number plan using the same script. > > I'm probably looking at it too simplistically, but, because a script can so > readily generate a zone file for any given input, the only benefit I can > see for the relative form is that it allows someone to manually tweak an > existing zone. (What would they do? Copy an existing set, and then edit > the $ORGIN line?) What I had in mind was to use DNAME. So, if 01954 8xxxx is migrating to 01954 78xxxx, you would go: $ORIGIN 4.5.9.1.4.4.e164.arpa. 8.7 DNAME 8 0.0.0.0.8 NAPTR .... 1.0.0.0.8 NAPTR .... etc. The send-n records would only work in this case if they were relative. > I would therefore strongly encourage the authors to drop the relative form > of send-n. It still seems sensible to me, but I'm not going to die in the ditch over it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 08:26:32 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087E128C1C4; Fri, 11 Jul 2008 08:26:32 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140AC28C1C4 for ; Fri, 11 Jul 2008 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9camKpmwONx for ; Fri, 11 Jul 2008 08:26:30 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id BE47728C19F for ; Fri, 11 Jul 2008 08:26:29 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6BDAEeR018479Fri, 11 Jul 2008 13:10:19 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KHIEi-0005zb-00; Fri, 11 Jul 2008 14:00:32 +0100 Date: Fri, 11 Jul 2008 14:00:32 +0100 From: "Clive D.W. Feather" To: Jim Reid Message-ID: <20080711130032.GG20707@finch-staff-1.thus.net> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: IETF ENUM WG Subject: Re: [Enum] Re send-n for query optimisation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid said: >>>But the ENUM lookups don't have to be blocking, >>>so why not let the client send an ENUM query after every digit (see >>>above >>>for prefix/area code considerations)? >> Because it's still load on the servers that would be worth reducing. > I'm not sure that this load is ever likely to be significant in the > overall scheme of things Clive. Is there any hard data here or are we > all just working on guesses? I don't have hard data, but I can give you some estimates. Say 50 million telephone users in the UK. Assume each averages 1 hour of calling per day, average call length 3 minutes, and a 25% failure rate of call attempts (no answer, engaged, etc.). Finally, assume a busy-hour ratio of 6:1. That's then about 87,000 call attempts per *second*. > How much query traffic could send-n > actually save as a proportion of the overall number of DNS lookups > that will be going on inside the NICC's private ENUM-like tree? For calls in the UK, as Paul has shown, you need a lookup at 8 digits - without send-N, that's therefore 4 lookups per call. Send-N will eliminate 2 of those. So that's 174,000 queries per second saved. > I > would assume that these lookups would be passing through some sort of > resolving server, so there should be a Big Win for cache hits after > the initial "priming" query. Let's assume caching gives you a 10:1 saving (I'm not at all clear it will be anywhere near that good), so that reduces it to a saving of 17,000 queries per second. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 09:02:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D574828C16B; Fri, 11 Jul 2008 09:02:30 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150D83A681F for ; Fri, 11 Jul 2008 09:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcpUqfu9gJXj for ; Fri, 11 Jul 2008 09:02:29 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id E8CAE3A67E3 for ; Fri, 11 Jul 2008 09:02:25 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6BDAEeP018479; Fri, 11 Jul 2008 13:10:16 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KHIGD-00060K-00 for enum@ietf.org; Fri, 11 Jul 2008 14:02:05 +0100 Date: Fri, 11 Jul 2008 14:02:05 +0100 From: "Clive D.W. Feather" To: enum@ietf.org Message-ID: <20080711130204.GH20707@finch-staff-1.thus.net> References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080701171113.GE1594@unknown.office.denic.de> User-Agent: Mutt/1.5.3i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter Koch said: >>> if you just let the client remember what a "full number" was; I've been >>> told this is already done. >> What do you mean by a "full number"? The whole problem is that it isn't a >> simple thing to determine. > It is, once you succeded to placing a call there. If the client (or the > PBX) remembers a list of dialed numbers, you can follow the digits until > you either match the number again or until you find the first differing > digit. Looking at my phone bill, there's little similarity in called numbers. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 09:25:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A6C3A6B2F; Fri, 11 Jul 2008 09:25:19 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A253A6B2F for ; Fri, 11 Jul 2008 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbnb6CTNwdBp for ; Fri, 11 Jul 2008 09:25:17 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 5B09C3A6AF6 for ; Fri, 11 Jul 2008 09:25:16 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6BGLQ7g020492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 11 Jul 2008 09:21:43 -0700 From: "Richard Shockey" To: Date: Fri, 11 Jul 2008 12:22:05 -0400 Message-ID: <05f401c8e372$54b7aec0$fe270c40$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjjckG0BQba5YQzS7CqFk3vilp9LQ== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] DRAFT AGENDA ... V2 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org IETF 72 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 5 M The following 3 drafts will be discussed concurrently. 15 M 2. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-10.txt Pages : 40 Date : 2008-05-19 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-10.tx t 3. Title : Update of legacy IANA Registrations of Enumservices Author(s) : B. Hoeneisen, A. Mayrhofer Filename : draft-hoeneisen-enum-enumservices-transition-01.txt Pages : 21 Date : 2008-05-20 This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-enumservices-transi tion-01.txt 4. Title : IANA Registration of Experimental and Trial Enumservices (X-Enumservices) Author(s) : B. Hoeneisen Filename : draft-ietf-enum-x-service-regs-01.txt Pages : 15 Date : 2008-05-21 This document specifies a new IANA registry for experimental and trial Enumservices (X-Enumservices), describes corresponding registration procedures, and provides a guideline for creating X-Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-x-service-regs-01.txt New ENUMservices... we need a quick discussion here leading to WG humm on action as WG items. 10 M 5. Title : IANA Registration for Location ('loc') Enumservice Author(s) : A. Mayrhofer Filename : draft-mayrhofer-enum-loc-enumservice-00.txt Pages : 9 Date : 2008-06-19 This document requests IANA registration of an Enumservice for reflecting location information. The Enumservice uses the 'loc' Type name, and makes use of the proposed 'held' and 'geo' URI schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-loc-enumservice-00. txt Main Event.. 15 Min 6. Title : IANA Registrations for the 'Send-N' Enumservice Author(s) : R. Bellis Filename : draft-bellis-enum-send-n-02.txt Pages : 11 Date : 2008-06-23 This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-02.txt 15 M ????? 7. New UNUSED ?????? Hadriel 8. New SOURCE URI ?? Hadriel Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 09:26:13 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DE73A6B2F; Fri, 11 Jul 2008 09:26:13 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334AD3A6B5E for ; Fri, 11 Jul 2008 09:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQa-0AlYH-GI for ; Fri, 11 Jul 2008 09:26:11 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id B83DB3A6B20 for ; Fri, 11 Jul 2008 09:26:10 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 581D1A77A9; Fri, 11 Jul 2008 17:26:27 +0100 (BST) Message-Id: <1C4E7248-9B55-49F5-93D9-723B7771004B@insensate.co.uk> From: Lawrence Conroy To: Clive D.W.Feather In-Reply-To: <20080711130032.GG20707@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 17:26:27 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080711130032.GG20707@finch-staff-1.thus.net> X-Mailer: Apple Mail (2.926) Cc: IETF ENUM WG , Jim Reid Subject: Re: [Enum] Re send-n for query optimisation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Clive, As Paul pointed out, this is not a UK-only problem. However, looking at your numbers, I think you are gilding the lilly. I disagree with your figures for the generality of UK telephone users. I would have used: 6 calls per day, 3-4 in busy two hour period. Average call length << 1 hour. As for call attempts / completed calls, I'd defer to Paul if he's willing to give out some numbers for his network. 4 call attempts per completed call seems high. Even so, we *are* talking about a DNS based system. Our friends in Verisign assure us all their servers are hammered much more than this. The total number of queries is distributed over the whole of the UK. You are thinking about a decentralized system, I hope? This is DNS. It also does cacheing. The propensity of people to call any individual number is low, but not always. Particularly with the "problem" ones in the UK, the propensity is likely to be much higher. For example, if we are to believe the Daily Mail and its ilk, there must be thousand upon thousand of calls to 0800 1111. This is going to remain resident in the cache of any provider's full-service resolver. If there are multiple queries for incomplete numbers, then these may also be in the "negative" cache. So - assuming a distributed system with separate authoritative servers and full-service resolvers, does it really matter whether or not one saves 50% or 75% of queries? There may well be some recommendations on negative cache times, but isn't that a DNSOPS issue, not one specifically for ENUM. all the best, Lawrence On 11 Jul 2008, at 14:00, Clive D.W. Feather wrote: > Jim Reid said: >>>> But the ENUM lookups don't have to be blocking, >>>> so why not let the client send an ENUM query after every digit (see >>>> above for prefix/area code considerations)? >>> Because it's still load on the servers that would be worth reducing. >> I'm not sure that this load is ever likely to be significant in the >> overall scheme of things Clive. Is there any hard data here or are we >> all just working on guesses? > > I don't have hard data, but I can give you some estimates. > > Say 50 million telephone users in the UK. Assume each averages 1 > hour of > calling per day, average call length 3 minutes, and a 25% failure > rate of > call attempts (no answer, engaged, etc.). Finally, assume a busy- > hour ratio > of 6:1. > > That's then about 87,000 call attempts per *second*. > >> How much query traffic could send-n >> actually save as a proportion of the overall number of DNS lookups >> that will be going on inside the NICC's private ENUM-like tree? > > For calls in the UK, as Paul has shown, you need a lookup at 8 > digits - > without send-N, that's therefore 4 lookups per call. Send-N will > eliminate > 2 of those. So that's 174,000 queries per second saved. > >> I >> would assume that these lookups would be passing through some sort of >> resolving server, so there should be a Big Win for cache hits after >> the initial "priming" query. > > Let's assume caching gives you a 10:1 saving (I'm not at all clear > it will > be anywhere near that good), so that reduces it to a saving of 17,000 > queries per second. > > -- > Clive D.W. Feather | Work: | Tel: +44 20 > 8495 6138 > Internet Expert | Home: | Fax: +44 870 > 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > 377646 > THUS plc | | > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 09:32:50 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9FE28C210; Fri, 11 Jul 2008 09:32:50 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB18528C209 for ; Fri, 11 Jul 2008 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBqFl0RHbIL3 for ; Fri, 11 Jul 2008 09:32:49 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 95A9528C216 for ; Fri, 11 Jul 2008 09:32:47 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 2C1C5A77B6; Fri, 11 Jul 2008 17:33:05 +0100 (BST) Message-Id: From: Lawrence Conroy To: Clive D.W.Feather In-Reply-To: <20080711130204.GH20707@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 11 Jul 2008 17:33:04 +0100 References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> <20080711130204.GH20707@finch-staff-1.thus.net> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi again Clive, again, I respectfully suggest that you are atypical. The numbers that you call may well be different from those called by your neighbours, but there is typically a fairly well defined called circle (albeit with "outliers") for most people - unless perhaps they run a one-man call centre. A counter-argument: In my case, I have many calls to a small set of numbers - the top 5 make up well over 2/3 of the number of calls I make (and *much* more in terms of total call length). all the best, Lawrence On 11 Jul 2008, at 14:02, Clive D.W. Feather wrote: > Looking at my phone bill, there's little similarity in called numbers. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 11 10:18:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A56928C16C; Fri, 11 Jul 2008 10:18:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5293A6B87 for ; Fri, 11 Jul 2008 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbdwWTtadHac for ; Fri, 11 Jul 2008 10:18:23 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id F2D333A6B7E for ; Fri, 11 Jul 2008 10:18:22 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KHMGT-0007eM-SB; Fri, 11 Jul 2008 19:18:37 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id B7ED17831D7; Fri, 11 Jul 2008 19:18:30 +0200 (CEST) Date: Fri, 11 Jul 2008 19:18:30 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080711171830.GI8491@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <48657FC5.2010205@e164.org> <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> <20080711130204.GH20707@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080711130204.GH20707@finch-staff-1.thus.net> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Fri, Jul 11, 2008 at 02:02:05PM +0100, Clive D.W. Feather wrote: > Looking at my phone bill, there's little similarity in called numbers. hmm, you don't call anybody twice? ;-) Also, not sure that a sample taken over a population of size one is a good approach. If the assuption didn't work I guess the technique would not be implemented. But again, some measurement would be fine. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 14 01:21:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805603A6BD6; Mon, 14 Jul 2008 01:21:20 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BCD3A6BD6 for ; Mon, 14 Jul 2008 01:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbmFL2mlZGFl for ; Mon, 14 Jul 2008 01:21:18 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 5164D3A6BED for ; Mon, 14 Jul 2008 01:17:25 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6E8Hm6C004268Mon, 14 Jul 2008 08:17:49 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KIJFk-000He3-00; Mon, 14 Jul 2008 09:17:48 +0100 Date: Mon, 14 Jul 2008 09:17:48 +0100 From: "Clive D.W. Feather" To: Lawrence Conroy Message-ID: <20080714081748.GG62734@finch-staff-1.thus.net> References: <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080711130032.GG20707@finch-staff-1.thus.net> <1C4E7248-9B55-49F5-93D9-723B7771004B@insensate.co.uk> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1C4E7248-9B55-49F5-93D9-723B7771004B@insensate.co.uk> User-Agent: Mutt/1.5.3i Cc: IETF ENUM WG , Jim Reid Subject: Re: [Enum] Re send-n for query optimisation X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence Conroy said: > As Paul pointed out, this is not a UK-only problem. > However, looking at your numbers, I think you are gilding the lilly. > I disagree with your figures for the generality of UK telephone users. > > I would have used: 6 calls per day, 3-4 in busy two hour period. > Average call length << 1 hour. Average call length of 3 minutes is, I believe, the standard used in UK telephony planning. I can't remember where I got the "1 hour usage per day" figure from, so I can't help with that. But my phone bill typically has at least 6 chargeable calls per day, and this excludes all off-peak calls to landlines in the UK (which are free on the package I'm subscribed to). > As for call attempts / completed calls, I'd defer to Paul if he's > willing to give out some numbers for his network. 4 call attempts > per completed call seems high. You misread; I'm suggesting 1.25 attempts per completed call (that is, one failure for every 4 successful calls). > The total number of queries is distributed over the whole of the UK. > You are thinking about a decentralized system, I hope? This is DNS. Yes, but the question is how many calls can be served off the caches and how many go back to the authoritative server. Plus it's not just the DNS. The switches have to make the queries and this takes CPU away from other tasks. Reducing the load on the switches is part of the objective. > It also does cacheing. The propensity of people to call any individual > number is low, but not always. Particularly with the "problem" ones in > the UK, the propensity is likely to be much higher. For example, if we > are to believe the Daily Mail and its ilk, Don't go there. Please. > there must be thousand upon > thousand of calls to 0800 1111. This is going to remain resident in the > cache of any provider's full-service resolver. True. But that doesn't help with other numbers. > So - assuming a distributed system with separate authoritative servers > and full-service resolvers, does it really matter whether or not one > saves 50% or 75% of queries? I would have still thought so, yes. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 14 01:24:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8743A685E; Mon, 14 Jul 2008 01:24:02 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44A23A6841 for ; Mon, 14 Jul 2008 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfZJtvL5cz8i for ; Mon, 14 Jul 2008 01:24:00 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id C89F43A685E for ; Mon, 14 Jul 2008 01:23:59 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6E8OOm6009541Mon, 14 Jul 2008 08:24:24 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KIJM8-000HoG-00; Mon, 14 Jul 2008 09:24:24 +0100 Date: Mon, 14 Jul 2008 09:24:24 +0100 From: "Clive D.W. Feather" To: Lawrence Conroy Message-ID: <20080714082424.GH62734@finch-staff-1.thus.net> References: <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> <20080711130204.GH20707@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence Conroy said: > Hi again Clive, > again, I respectfully suggest that you are atypical. > The numbers that you call may well be different from those called by > your neighbours, but there is typically a fairly well defined called > circle (albeit with "outliers") for most people - unless perhaps they > run a one-man call centre. > > A counter-argument: In my case, I have many calls to a small set of > numbers - the top 5 make up well over 2/3 of the number of calls I make > (and *much* more in terms of total call length). > On 11 Jul 2008, at 14:02, Clive D.W. Feather wrote: >> Looking at my phone bill, there's little similarity in called numbers. I think there's a misunderstanding here. Peter wrote: | >> if you just let the client remember what a "full number" was; I've been | >> told this is already done. | > What do you mean by a "full number"? The whole problem is that it isn't a | > simple thing to determine. | It is, once you succeded to placing a call there. If the client (or the | PBX) remembers a list of dialed numbers, you can follow the digits until | you either match the number again or until you find the first differing | digit. I read this as a suggestion along the lines of: customer calls 01234567890, therefore you can deduce that other numbers beginning 012345678 are the same length. To which my reply was trying to point out that there's little commonality between the *different* numbers that I call. This may be a UK v US thing: the numbers I call frequently are in several area codes, and even those in the same area code will be in different DG groups (the 56 in the above example). That's what I meant by "little similarity". Perhaps Peter can re-explain his suggestion, since I clearly didn't understand it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From cabinetguy@cabinetguy.net Mon Jul 14 10:12:15 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95D53A6809; Mon, 14 Jul 2008 10:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.641 X-Spam-Level: X-Spam-Status: No, score=-28.641 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spmqagf7L0uL; Mon, 14 Jul 2008 10:12:15 -0700 (PDT) Received: from pc-179-69-47-190.cm.vtr.net (pc-179-69-47-190.cm.vtr.net [190.47.69.179]) by core3.amsl.com (Postfix) with SMTP id ED66428C193; Mon, 14 Jul 2008 10:11:21 -0700 (PDT) X-Originating-IP: 240.66.105.177 by smtp.190.47.69.179; Mon, 14 Jul 2008 13:11:47 -0500 Message-ID: From: "Herschel Dubois" Reply-To: "Herschel Dubois" To: edu-discuss-request@ietf.org Subject: Classical Frank Muller watches at Prestige Replicas Date: Mon, 14 Jul 2008 13:11:47 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www.rrpple.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www.rrpple.com/ From enum-bounces@ietf.org Mon Jul 14 13:00:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7693A6C89; Mon, 14 Jul 2008 13:00:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055153A6C83 for ; Mon, 14 Jul 2008 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-knbBkjRhhB for ; Mon, 14 Jul 2008 13:00:31 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id A538728C3E4 for ; Mon, 14 Jul 2008 12:59:30 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6EJtER5018318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Jul 2008 12:55:30 -0700 From: "Richard Shockey" To: Date: Mon, 14 Jul 2008 15:55:43 -0400 Message-ID: <195701c8e5eb$ad62d5b0$08288110$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1958_01C8E5CA.265135B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjl5efXOYX0pHIvSde0RutF/EccTQABa2SQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_1958_01C8E5CA.265135B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 14, 2008 3:00 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-timms-encrypt-naptr-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for Encrypted ENUM Author(s) : B. Timms, J. Reid, J. Schlyter Filename : draft-timms-encrypt-naptr-01.txt Pages : 21 Date : 2008-7-12 This document requests IANA registration of the "X-Crypto" Enumservice. This Enumservice indicates that its NAPTR holds a Uniform Resource Identifier that carries encrypted content from the fields of another (unpublished) Protected NAPTR, for use in E.164 Number Mapping (ENUM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_1958_01C8E5CA.265135B0 Content-Type: Message/External-body; name="draft-timms-encrypt-naptr-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-timms-encrypt-naptr-01.txt" Content-Type: text/plain Content-ID: <2008-7-14115315.I-D@ietf.org> ------=_NextPart_000_1958_01C8E5CA.265135B0 Content-Type: text/plain; name="ATT06410.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT06410.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_1958_01C8E5CA.265135B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum ------=_NextPart_000_1958_01C8E5CA.265135B0-- From enum-bounces@ietf.org Mon Jul 14 19:36:17 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93123A68E4; Mon, 14 Jul 2008 19:36:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8AB3A67D9 for ; Mon, 14 Jul 2008 19:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va1uRy3aVEuC for ; Mon, 14 Jul 2008 19:36:15 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 4BEE03A68E4 for ; Mon, 14 Jul 2008 19:36:15 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id F39D4FF33B; Tue, 15 Jul 2008 12:36:43 +1000 (EST) Message-ID: <487C0CB8.8010008@e164.org> Date: Tue, 15 Jul 2008 12:34:32 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Richard Shockey , "enum@ietf.org" References: <195701c8e5eb$ad62d5b0$08288110$@us> In-Reply-To: <195701c8e5eb$ad62d5b0$08288110$@us> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] {Dangerous Content?} FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard Shockey wrote: This is a nice idea, but the proposal will only hide the reply, it won't prevent information from leaking. I actually used his previous draft as inspiration for a draft to encrypt both requests and replies to prevent information leaking. I'm fixing up the current draft as it is flawed in a number of ways (received feed back from the dnsext working group) and I was hoping to have the new draft up before posting about it to this list. http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-01.txt http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-01.pdf -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 14 21:07:10 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20B528C14C; Mon, 14 Jul 2008 21:07:10 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE1D28C0F1 for ; Mon, 14 Jul 2008 21:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V12OIlvylFTw for ; Mon, 14 Jul 2008 21:07:08 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 87BEE3A689C for ; Mon, 14 Jul 2008 21:07:08 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id C8C02FF33D; Tue, 15 Jul 2008 14:07:37 +1000 (EST) Message-ID: <487C2205.1030009@e164.org> Date: Tue, 15 Jul 2008 14:05:25 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Richard Shockey , "enum@ietf.org" References: <195701c8e5eb$ad62d5b0$08288110$@us> <487C0CB8.8010008@e164.org> In-Reply-To: <487C0CB8.8010008@e164.org> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Duane wrote: > Richard Shockey wrote: > > This is a nice idea, but the proposal will only hide the reply, it won't > prevent information from leaking. > > I actually used his previous draft as inspiration for a draft to encrypt > both requests and replies to prevent information leaking. I'm fixing up > the current draft as it is flawed in a number of ways (received feed > back from the dnsext working group) and I was hoping to have the new > draft up before posting about it to this list. The updated revision is now online: http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.txt http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.pdf -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 03:07:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E543A6949; Tue, 15 Jul 2008 03:07:27 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3D03A693E for ; Tue, 15 Jul 2008 03:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJAgad9yd8YC for ; Tue, 15 Jul 2008 03:07:25 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id CE1013A6949 for ; Tue, 15 Jul 2008 03:07:24 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1DFADA84F0; Tue, 15 Jul 2008 11:07:51 +0100 (BST) Message-Id: <5ABA1062-5600-49FA-AC3C-138FC102DAC9@insensate.co.uk> From: Lawrence Conroy To: Richard Shockey In-Reply-To: <195701c8e5eb$ad62d5b0$08288110$@us> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 11:07:50 +0100 References: <195701c8e5eb$ad62d5b0$08288110$@us> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, (channeling Jim who's out of email range): This is a refresh of the original draft, with added examples, expanded security considerations and a few random textual clarifications. The basic concept is the same. all the best, Lawrence On 14 Jul 2008, at 20:55, Richard Shockey wrote: > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org > ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 14, 2008 3:00 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-timms-encrypt-naptr-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Registration for Encrypted ENUM > Author(s) : B. Timms, J. Reid, J. Schlyter > Filename : draft-timms-encrypt-naptr-01.txt > Pages : 21 > Date : 2008-7-12 > > This document requests IANA registration of the "X-Crypto" > Enumservice. This Enumservice indicates that its NAPTR holds a > Uniform Resource Identifier that carries encrypted content from the > fields of another (unpublished) Protected NAPTR, for use in E.164 > Number Mapping (ENUM). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-7-14115315.I-D@ietf.org> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 04:38:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065103A6982; Tue, 15 Jul 2008 04:38:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DCB3A67D9 for ; Tue, 15 Jul 2008 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDo8yXEFZNBi for ; Tue, 15 Jul 2008 04:38:06 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 02D6D3A6992 for ; Tue, 15 Jul 2008 04:38:05 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KIirU-0005H3-DE; Tue, 15 Jul 2008 13:38:28 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0F9D97BD6C2; Tue, 15 Jul 2008 13:38:27 +0200 (CEST) Date: Tue, 15 Jul 2008 13:38:27 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080715113827.GF72171@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <20080629132325.GA23998@x27.adm.denic.de> <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> <20080711130204.GH20707@finch-staff-1.thus.net> <20080714082424.GH62734@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080714082424.GH62734@finch-staff-1.thus.net> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Mon, Jul 14, 2008 at 09:24:24AM +0100, Clive D.W. Feather wrote: > I read this as a suggestion along the lines of: customer calls 01234567890, > therefore you can deduce that other numbers beginning 012345678 are the same > length. the idea is to notice differences, not similarities. If the customer called 01234567890 and dials 012345679999 next, the client would have to probe (query for NAPTR, feed into an ENUM lookup) starting with only 012345679, because that's the first differing digit. There is no conclusion drawn about the length of 012345679*, because there are just too many options, at least in +49. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 05:15:21 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23483A6801; Tue, 15 Jul 2008 05:15:21 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464F63A6801 for ; Tue, 15 Jul 2008 05:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mexlWQkeIHIU for ; Tue, 15 Jul 2008 05:15:19 -0700 (PDT) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 5492D3A67DF for ; Tue, 15 Jul 2008 05:15:19 -0700 (PDT) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KIjRZ-0003rj-3V for enum@ietf.org; Tue, 15 Jul 2008 13:15:45 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out4.blueyonder.co.uk with esmtp (Exim 4.52) id 1KIjRY-0002TA-MK for enum@ietf.org; Tue, 15 Jul 2008 13:15:44 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 0DB241C463D8 for ; Tue, 15 Jul 2008 13:15:44 +0100 (BST) Message-Id: <04DD6C3A-8CC9-4CBB-9A75-22BBFAF75C5D@games-with-brains.com> From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: <487C0CB8.8010008@e164.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Jul 2008 13:15:44 +0100 References: <195701c8e5eb$ad62d5b0$08288110$@us> <487C0CB8.8010008@e164.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] {Dangerous Content?} FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 15 Jul 2008, at 03:34, Duane wrote: > This is a nice idea, but the proposal will only hide the reply, it > won't > prevent information from leaking. > > I actually used his previous draft as inspiration for a draft to > encrypt > both requests and replies to prevent information leaking. It's a very interesting draft and I hope it gains some traction. However it solves a fundamentally different problem to the X-Crypto service, which is purely concerned with using a DNS NAPTR as a private data store for ENUM-style services with key management infrastructure provided out of band. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 12:01:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2468528C19D; Tue, 15 Jul 2008 12:01:30 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD4928C17D for ; Tue, 15 Jul 2008 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoLf-aqwzR+F for ; Tue, 15 Jul 2008 12:01:27 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 4C8CA28C25F for ; Tue, 15 Jul 2008 12:00:55 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 80485FF29C; Wed, 16 Jul 2008 05:01:09 +1000 (EST) Message-ID: <487CF34B.3010301@e164.org> Date: Wed, 16 Jul 2008 04:58:19 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Eleanor McHugh , "enum@ietf.org" References: <195701c8e5eb$ad62d5b0$08288110$@us> <487C0CB8.8010008@e164.org> <04DD6C3A-8CC9-4CBB-9A75-22BBFAF75C5D@games-with-brains.com> In-Reply-To: <04DD6C3A-8CC9-4CBB-9A75-22BBFAF75C5D@games-with-brains.com> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] {Dangerous Content?} FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Eleanor McHugh wrote: > On 15 Jul 2008, at 03:34, Duane wrote: >> This is a nice idea, but the proposal will only hide the reply, it won't >> prevent information from leaking. >> >> I actually used his previous draft as inspiration for a draft to encrypt >> both requests and replies to prevent information leaking. > > It's a very interesting draft and I hope it gains some traction. However > it solves a fundamentally different problem to the X-Crypto service, > which is purely concerned with using a DNS NAPTR as a private data store > for ENUM-style services with key management infrastructure provided out > of band. I realise that, but my point was that it may not prevent information from leaking and even the authors acknowledge that in the draft, which is partly where the inspiration came from. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 16:34:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90903A685C; Tue, 15 Jul 2008 16:34:31 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB4E3A67CF for ; Tue, 15 Jul 2008 16:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gjN3HGn9Owo for ; Tue, 15 Jul 2008 16:34:29 -0700 (PDT) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 6AF103A69A3 for ; Tue, 15 Jul 2008 16:34:29 -0700 (PDT) Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KIu2q-0004mp-Hc for enum@ietf.org; Wed, 16 Jul 2008 00:34:56 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52) id 1KIu2q-0007jU-1m for enum@ietf.org; Wed, 16 Jul 2008 00:34:56 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 5CB3E1C5872F for ; Wed, 16 Jul 2008 00:34:55 +0100 (BST) Message-Id: From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: <487CF34B.3010301@e164.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Jul 2008 00:34:55 +0100 References: <195701c8e5eb$ad62d5b0$08288110$@us> <487C0CB8.8010008@e164.org> <04DD6C3A-8CC9-4CBB-9A75-22BBFAF75C5D@games-with-brains.com> <487CF34B.3010301@e164.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] {Dangerous Content?} FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 15 Jul 2008, at 19:58, Duane wrote: > Eleanor McHugh wrote: >> On 15 Jul 2008, at 03:34, Duane wrote: >>> This is a nice idea, but the proposal will only hide the reply, it >>> won't >>> prevent information from leaking. >>> >>> I actually used his previous draft as inspiration for a draft to >>> encrypt >>> both requests and replies to prevent information leaking. >> >> It's a very interesting draft and I hope it gains some traction. >> However >> it solves a fundamentally different problem to the X-Crypto service, >> which is purely concerned with using a DNS NAPTR as a private data >> store >> for ENUM-style services with key management infrastructure provided >> out >> of band. > > I realise that, but my point was that it may not prevent information > from leaking and even the authors acknowledge that in the draft, which > is partly where the inspiration came from. Which is why I hope it gains traction ;) Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 15 17:05:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C9D3A6A30; Tue, 15 Jul 2008 17:05:25 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1E43A691E for ; Tue, 15 Jul 2008 17:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krlMNTog4syF for ; Tue, 15 Jul 2008 17:05:23 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id AF1083A6A30 for ; Tue, 15 Jul 2008 17:05:23 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E0746FF292 for ; Wed, 16 Jul 2008 09:57:32 +1000 (EST) Message-ID: <487D38DF.8010309@e164.org> Date: Wed, 16 Jul 2008 09:55:11 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <195701c8e5eb$ad62d5b0$08288110$@us> <487C0CB8.8010008@e164.org> <04DD6C3A-8CC9-4CBB-9A75-22BBFAF75C5D@games-with-brains.com> <487CF34B.3010301@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] {Dangerous Content?} FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Eleanor McHugh wrote: > Which is why I hope it gains traction ;) Well I've had some dismissive comments, but I've had some good technical feed back too, something I didn't get until I submitted it into the DNSEXT working group. I'm following up on the suggestions and comments at present. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From calendar-invite@reply.yahoo.com Wed Jul 16 02:11:34 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866C128C19C for ; Wed, 16 Jul 2008 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.674 X-Spam-Level: **** X-Spam-Status: No, score=4.674 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, ADVANCE_FEE_3=1.432, BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, NA_DOLLARS=1.329, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSnkvVQ1gW4h for ; Wed, 16 Jul 2008 02:11:33 -0700 (PDT) Received: from n27a.bullet.scd.yahoo.com (n27a.bullet.scd.yahoo.com [209.73.160.72]) by core3.amsl.com (Postfix) with SMTP id B68CC3A6846 for ; Wed, 16 Jul 2008 02:11:33 -0700 (PDT) Received: from [209.73.164.83] by n27.bullet.scd.yahoo.com with NNFMP; 16 Jul 2008 09:11:35 -0000 Received: from [68.142.194.243] by t7.bullet.scd.yahoo.com with NNFMP; 16 Jul 2008 09:11:35 -0000 Received: from [209.191.93.243] by t1.bullet.mud.yahoo.com with NNFMP; 16 Jul 2008 09:11:35 -0000 Date: 16 Jul 2008 02:11:35 -0700 Received: from [127.0.0.1] by web120.cal.pim.mud.yahoo.com with NNFMP; 16 Jul 2008 09:11:34 -0000 x-yahoo-newman-errors: calendar-invite.mrqw4x3bha4dki3kniwtcmrrgyytsojuhe2c2zdbnzpwcobygurwu2r2g42q-enum-archive=ietf.org@returns.bulk.yahoo.com MIME-Version: 1.0 Reply-to: dan_a885@yahoo.com Errors-To: dan_a885@yahoo.com From: Dan Akan To: enum-archive@ietf.org Subject: FROM THE DESK OF MR, DAN AKEN.. X-Yahoo-Newman-Property: calendar-invite X-Yahoo-Newman-Id: dan_a885#jj-1216199494-dan_a885#jj:75 X-Yahoo-Calendar-Iid: axQiYwl%40wMNoarumRh%40NJEh%40Yfb%40 X-RocketSRV: siu=http://us.i1.yimg.com/us.yimg.com/i/us/pim/el/inv16_1.gif;siw=16;sih=16;allow=all Content-Type: multipart/alternative; boundary="YCalInvites=mstpkYLl3vYacTuFr4kYGQix3EPI0SW1216199484-1" Message-Id: <20080716091133.B68CC3A6846@core3.amsl.com> --YCalInvites=mstpkYLl3vYacTuFr4kYGQix3EPI0SW1216199484-1 Content-type: text/plain; charset=windows-1252; You are invited to "FROM THE DESK OF MR, DAN AKEN..". By your host Dan Akan: FROM THE DESK OF MR, DAN AKEN.. BILL AND EXCHANGE MANAGER.. BANK OF AFRICA.. OAUGADOUGOU BURKINA FASO.. WEST AFRICA.. I am mr,da aken. The manager of bill and exchange at the foreign remittance department of Bank of Africa. In my department we discovered an abandoned sum of US$20.5M (twenty million, five hundred thousand US dollars) in an account that belongs to one of our foreign customer who died along with his entire family in August 17, 1999 at earth quake in Izmir Date: Wednesday July 16, 2008 Time: 8:00 am - 9:00 am (GMT +00:00) Will you attend? RSVP to this invitation at: http://calendar.yahoo.com/dan_a885?v=126&a1=0&iid=axQiYwl%40wMNoarumRh%40NJEh%40Yfb%40&igid=6xAx%40p3ec05j%40bVhBhh6lG%40%40MgVTA%40uH Copyright © 2008 All Rights Reserved www.yahoo.com Privacy Policy: http://privacy.yahoo.com/privacy/us Terms of Service: http://docs.yahoo.com/info/terms/ --YCalInvites=mstpkYLl3vYacTuFr4kYGQix3EPI0SW1216199484-1 Content-type: text/html; charset=windows-1252;
You're invited to:   FROM THE DESK OF MR, DAN AKEN..
By your host:   Dan Akan
 
Message:   FROM THE DESK OF MR, DAN AKEN..

BILL AND EXCHANGE MANAGER..

BANK OF AFRICA..

OAUGADOUGOU BURKINA FASO..

WEST AFRICA..




I am mr,da aken. The manager of bill and exchange at the foreign remittance department of Bank of Africa. In my department we discovered an abandoned sum of US$20.5M (twenty million, five hundred thousand US dollars) in an account that belongs to one of our foreign customer who died along with his entire family in August 17, 1999 at earth quake in Izmir
 
Date:   Wednesday July 16, 2008
Time:   8:00 am - 9:00 am  (GMT +00:00)
 
Will you attend?   RSVP to this invitation
Copyright © 2008  Yahoo! Inc. All Rights Reserved | Terms of Service | Privacy Policy
--YCalInvites=mstpkYLl3vYacTuFr4kYGQix3EPI0SW1216199484-1-- From enum-bounces@ietf.org Wed Jul 16 03:34:55 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1206528C2A4; Wed, 16 Jul 2008 03:34:55 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EEE28C2A4 for ; Wed, 16 Jul 2008 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4sTX-Gt03G4 for ; Wed, 16 Jul 2008 03:34:53 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 29BA528C299 for ; Wed, 16 Jul 2008 03:34:52 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6GAYkrQ015565; Wed, 16 Jul 2008 10:35:20 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KJ3jD-000Ma3-00 for enum@ietf.org; Wed, 16 Jul 2008 10:55:19 +0100 Date: Wed, 16 Jul 2008 10:55:19 +0100 From: "Clive D.W. Feather" To: IETF ENUM WG Message-ID: <20080716095519.GF76206@finch-staff-1.thus.net> References: <20080630160805.GK487@unknown.office.denic.de> <20080701142735.GB1594@unknown.office.denic.de> <20080701143455.GD89909@finch-staff-1.thus.net> <20080701171113.GE1594@unknown.office.denic.de> <20080711130204.GH20707@finch-staff-1.thus.net> <20080714082424.GH62734@finch-staff-1.thus.net> <20080715113827.GF72171@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080715113827.GF72171@unknown.office.denic.de> User-Agent: Mutt/1.5.3i Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter Koch said: > the idea is to notice differences, not similarities. If the customer called > 01234567890 and dials 012345679999 next, the client would have to probe (query > for NAPTR, feed into an ENUM lookup) starting with only 012345679, because > that's the first differing digit. There is no conclusion drawn about the > length of 012345679*, because there are just too many options, at least in +49. Ah, I see. I have no idea how that would play out in general. In the case of the numbers I call frequently, they rarely match longer than the 01234 stage. Of course, in our problem domain the "client" is a local or even regional switch or callserver. I'm not sure how well that approach would work. There's also the question of how long you can assume the conclusion is valid. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From hr.publicnotice@live.co.uk Wed Jul 16 18:53:45 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B3B3A69EA for ; Wed, 16 Jul 2008 18:53:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char DC hex): X-Mailer: U.\334.WebMail Servis[...] X-Spam-Flag: NO X-Spam-Score: 3.013 X-Spam-Level: *** X-Spam-Status: No, score=3.013 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TR=0.935, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyRVrAj9Y1Xj for ; Wed, 16 Jul 2008 18:53:45 -0700 (PDT) Received: from mail.uludag.edu.tr (uludag.edu.tr [193.140.245.222]) by core3.amsl.com (Postfix) with SMTP id 86AED3A67B3 for ; Wed, 16 Jul 2008 18:53:34 -0700 (PDT) Received: from mppd (uludag.edu.tr [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id BBE46172DCD; Thu, 17 Jul 2008 04:46:41 +0300 (EEST) Received: from uludag.edu.tr (uludag.edu.tr [127.0.0.1]) by mail.uludag.edu.tr (Postfix) with ESMTP id 61ED9172894; Thu, 17 Jul 2008 04:46:40 +0300 (EEST) From: "British Petroleum Board" Reply-To: human.resourcesgroups@googlemail.com Subject: MESSAGE FROM THE BRITISH PETROLEUM COMPANY UK, PETROLEUM DEPT., TREAT AS A MATTER OF URGENCY Date: Wed, 16 Jul 2008 21:46:40 -0400 Message-Id: <20080717014641.M59418@live.co.uk> X-Mailer: U.Ü.WebMail Servisi 2.51 20050228 X-OriginatingIP: 78.138.0.102 (parasite) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-Scanned-By: MPP/Cloudmark http://www.messagepartners.com X-Scanned-By: This message was scanned by MPP v.3 (www.messagepartners.com) X-Scanned-By: MPP/Nod32 http://www.messagepartners.com BP JOB ALERT Ref No:01/007/HRD/BPPLC British Petroleum Company wishes to announce to the general public about if 2ND Quota Recruitment excise which is currently going on now.For our three (3)newly commissioned offices around United Kingdom. This vacancies are to fill up the offices of our newly opened branches in the UK Resourceful applicant with qualified Grad/Result should forward all qualification to the office of the Human Resources Officer for Screening. Stated Below is the full details to the HRD: Officer:Mr.Anderson Spencer Head Human Resources Officer Email: human.resourcesgroups@googlemail.com Do contact the department with an update of your resume. Qualified Applicant will be invited to London for their interview after screening. Regards, HR Department British Petroleum Company UK From hr.publicnotice@live.co.uk Thu Jul 17 02:31:12 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838AA3A67F1 for ; Thu, 17 Jul 2008 02:31:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char DC hex): X-Mailer: U.\334.WebMail Servis[...] X-Spam-Flag: NO X-Spam-Score: 4.038 X-Spam-Level: **** X-Spam-Status: No, score=4.038 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_TR=0.935, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A72ExZGtSvTV for ; Thu, 17 Jul 2008 02:31:11 -0700 (PDT) Received: from mail.uludag.edu.tr (unknown [193.140.245.222]) by core3.amsl.com (Postfix) with SMTP id 3455C3A6817 for ; Thu, 17 Jul 2008 02:31:00 -0700 (PDT) Received: from mppd (uludag.edu.tr [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 61120469371; Thu, 17 Jul 2008 05:50:08 +0300 (EEST) Received: from uludag.edu.tr (uludag.edu.tr [127.0.0.1]) by mail.uludag.edu.tr (Postfix) with ESMTP id 587E3180352; Thu, 17 Jul 2008 05:43:49 +0300 (EEST) From: "British Petroleum Board" Reply-To: human.resourcesgroups@googlemail.com Subject: MESSAGE FROM THE BRITISH PETROLEUM COMPANY UK, PETROLEUM DEPT., TREAT AS A MATTER OF URGENCY Date: Wed, 16 Jul 2008 22:43:49 -0400 Message-Id: <20080717024350.M26508@live.co.uk> X-Mailer: U.Ü.WebMail Servisi 2.51 20050228 X-OriginatingIP: 78.138.0.102 (parasite) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-Scanned-By: MPP/Cloudmark http://www.messagepartners.com X-Scanned-By: This message was scanned by MPP v.3 (www.messagepartners.com) X-Scanned-By: MPP/Nod32 http://www.messagepartners.com BP JOB ALERT Ref No:01/007/HRD/BPPLC British Petroleum Company wishes to announce to the general public about if 2ND Quota Recruitment excise which is currently going on now.For our three (3)newly commissioned offices around United Kingdom. This vacancies are to fill up the offices of our newly opened branches in the UK Resourceful applicant with qualified Grad/Result should forward all qualification to the office of the Human Resources Officer for Screening. Stated Below is the full details to the HRD: Officer:Mr.Anderson Spencer Head Human Resources Officer Email: human.resourcesgroups@googlemail.com Do contact the department with an update of your resume. Qualified Applicant will be invited to London for their interview after screening. Regards, HR Department British Petroleum Company UK From enum-bounces@ietf.org Thu Jul 17 11:18:29 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FB63A6AAE; Thu, 17 Jul 2008 11:18:29 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779073A6AAE for ; Thu, 17 Jul 2008 11:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5sxWDOwKbxT for ; Thu, 17 Jul 2008 11:18:26 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 3FC4E3A6A06 for ; Thu, 17 Jul 2008 11:18:25 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6HIFOg4019459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Jul 2008 11:15:41 -0700 From: "Richard Shockey" To: References: <195701c8e5eb$ad62d5b0$08288110$@us> In-Reply-To: <195701c8e5eb$ad62d5b0$08288110$@us> Date: Thu, 17 Jul 2008 14:15:47 -0400 Message-ID: <01d301c8e839$36496a20$a2dc3e60$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjl5efXOYX0pHIvSde0RutF/EccTQABa2SQAJNd8rA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Is this an agenda item?????? > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 14, 2008 3:00 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-timms-encrypt-naptr-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Registration for Encrypted ENUM > Author(s) : B. Timms, J. Reid, J. Schlyter > Filename : draft-timms-encrypt-naptr-01.txt > Pages : 21 > Date : 2008-7-12 > > This document requests IANA registration of the "X-Crypto" > Enumservice. This Enumservice indicates that its NAPTR holds a > Uniform Resource Identifier that carries encrypted content from the > fields of another (unpublished) Protected NAPTR, for use in E.164 > Number Mapping (ENUM). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From veronika.bruin@igt.com Thu Jul 17 13:31:16 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22B23A67F8 for ; Thu, 17 Jul 2008 13:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.302 X-Spam-Level: X-Spam-Status: No, score=-29.302 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_DYNAMIC_HOME_NL=3.463, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmm6dwe3X2j5 for ; Thu, 17 Jul 2008 13:31:16 -0700 (PDT) Received: from cp868263-b.ndwrt1.lb.home.nl (cp868263-b.ndwrt1.lb.home.nl [213.51.72.192]) by core3.amsl.com (Postfix) with SMTP id A0F213A6813 for ; Thu, 17 Jul 2008 13:31:15 -0700 (PDT) Message-Id: <20080717113138.5251.qmail@cp868263-b.ndwrt1.lb.home.nl> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Thu, 17 Jul 2008 13:31:15 -0700 (PDT)
From enum-bounces@ietf.org Thu Jul 17 15:29:43 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C743A692C; Thu, 17 Jul 2008 15:29:43 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B63E3A692C for ; Thu, 17 Jul 2008 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuCnidR8j2ZA for ; Thu, 17 Jul 2008 15:29:40 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id CCE2F3A6831 for ; Thu, 17 Jul 2008 15:29:40 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A1483FF292 for ; Fri, 18 Jul 2008 08:30:14 +1000 (EST) Message-ID: <487FC754.60301@e164.org> Date: Fri, 18 Jul 2008 08:27:32 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" X-Enigmail-Version: 0.95.0 Subject: [Enum] Updated draft-groth-dns-encryption X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I'm unable to publish on the IETF site due to the cut off so I've put it on ours for the time being until submissions are accepted again. http://www.e164.org/docs/draft-groth-dns-encryption-03.txt http://www.e164.org/docs/draft-groth-dns-encryption-03.pdf There is a lot of differences with this draft compared to previous ones, hopefully this one is a lot more suitable, but this is the first submission I've been directly involved with, the learning curve has been straight up. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jul 17 15:41:01 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44983A6812; Thu, 17 Jul 2008 15:41:01 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F9F3A6812 for ; Thu, 17 Jul 2008 15:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx+GvbZZeO-W for ; Thu, 17 Jul 2008 15:41:00 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 767BE3A67B0 for ; Thu, 17 Jul 2008 15:41:00 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 6075DFF292 for ; Fri, 18 Jul 2008 08:41:34 +1000 (EST) Message-ID: <487FC9FA.8030403@e164.org> Date: Fri, 18 Jul 2008 08:38:50 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: <48657FC5.2010205@e164.org> <002f01c8dad6$b9bee0d0$ea00a8c0@Codalogic> <20080711124636.GF20707@finch-staff-1.thus.net> In-Reply-To: <20080711124636.GF20707@finch-staff-1.thus.net> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org If this information must go in DNS I agree with everyone else that suggested this should get it's own DNS type, it would if nothing else reduce the size of the DNS packet substantially, as well as not interfere with NAPTR wildcards. Although I thought it was a weak argument about offloading processing, since the processing has to be done somewhere no matter what. Having a new DNS type it would only need 1 byte for data, which would speed up processing of the information since it doesn't need to deal with regex and so on. DNS Type SENDN ID to be assigned by IANA, packet structure: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |MinDig |MaxDig | +-+-+-+-+-+-+-+-+ Since the maximum length can only be 15 this fits perfectly inside a nibble :) -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 00:53:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924893A688E; Fri, 18 Jul 2008 00:53:08 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DEA3A688E for ; Fri, 18 Jul 2008 00:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbLDCfwRgxH7 for ; Fri, 18 Jul 2008 00:53:06 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 860D33A688C for ; Fri, 18 Jul 2008 00:53:06 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=Nf9JR6zSS1pAMyG+6nVQdjAFmjDc/Hihyy/Sx9NYaL+bNzo4UZWubxQ6 8N4Tifn+xL4Gb4lEMtFA9AVje0WYrU7G2DRGwwnC5FXBej3ehUf5yOYTY l9s8WDr/qcvWatZ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216367620; x=1247903620; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Fri,=2018=20Jul=202008=2008:53:37=20+0100 |Message-ID:=20|To:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<487FC9FA.8030403@e16 4.org>; bh=5F5+d5C1DlNKrSj2xLaD2B6K1cbqKU7d9F/BPx8myao=; b=lIMfh30Lv1+wE91o3+E5/2uOg7vVX6MZlRrV2dbBWr8xV5HLoCvHEW4K OUsFRvRbn5EN+a85/YbcJ6Tzk3B6UgqYbdsz2hhUIS18fz9XKT6Y3tC3F ivgkuW7t+2siA+E; X-IronPort-AV: E=Sophos;i="4.31,209,1215385200"; d="scan'208";a="4196491" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Jul 2008 08:53:37 +0100 In-Reply-To: <487FC9FA.8030403@e164.org> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 18 Jul 2008 08:53:37 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/07/2008 08:53:37 AM, Serialize complete at 18/07/2008 08:53:37 AM Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > If this information must go in DNS I agree with everyone else that > suggested this should get it's own DNS type, it would if nothing else > reduce the size of the DNS packet substantially, as well as not > interfere with NAPTR wildcards. I don't believe there's anything like consensus on this. For example I recall Lawrence specifically agreeing that getting the Send-N response as an automatic side-effect of an ENUM lookup was a good thing. Also see Roy's message of 30/06 where it was explained how using a different RRtype doesn't affect wildcard processing - a more specific RRset containing *any* RRtype will prevent any wildcard expansion that would otherwise have succeeded. However it's perfectly acceptable to put the Send-N in the wildcard RRset, or in a less specific RRset. Personally I don't like the bloat of NAPTRs either, but for performance reasons we (NICC that is) consider that getting an answer back in one round-trip is more important than the size of the response. If someone can propose a way to use a new RR-type which works with an optimal number of packets (i.e. 1) rather than size of packets then I'm open to it. Jim Reid had suggested (off-list) that the Additional Section could be used for this. However that would require any DNS server software implementing Send-N to be engineered to return this data there if the requested NAPTR doesn't exist. The DNS clients would also need to be engineered to actually look in that Additional Section if there's nothing in the Answer Section. > Although I thought it was a weak argument about offloading processing, > since the processing has to be done somewhere no matter what. > > Having a new DNS type it would only need 1 byte for data, which would > speed up processing of the information since it doesn't need to deal > with regex and so on. > > DNS Type SENDN ID to be assigned by IANA, packet structure: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |MinDig |MaxDig | > +-+-+-+-+-+-+-+-+ > > Since the maximum length can only be 15 this fits perfectly inside a > nibble :) Except for flags to indicate absolute vs relative :) Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 02:06:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9982A3A690A; Fri, 18 Jul 2008 02:06:12 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2163A690A for ; Fri, 18 Jul 2008 02:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA15vukoBWqi for ; Fri, 18 Jul 2008 02:06:10 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id AEDA23A6933 for ; Fri, 18 Jul 2008 02:06:10 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 46117FF270; Fri, 18 Jul 2008 19:06:40 +1000 (EST) Message-ID: <48805C7B.8090303@e164.org> Date: Fri, 18 Jul 2008 19:03:55 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: In-Reply-To: X-Enigmail-Version: 0.95.0 Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: > If someone can propose a way to use a new RR-type which works with an > optimal number of packets (i.e. 1) rather than size of packets then I'm > open to it. You use the new DNS RR in the same way(s) you are proposing to use a NAPTR record. As I said in my previous email, a new RR type wouldn't have all the regex/text processing overhead so using binary parsing would speed things up considerably. >> DNS Type SENDN ID to be assigned by IANA, packet structure: >> >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> |MinDig |MaxDig | >> +-+-+-+-+-+-+-+-+ >> >> Since the maximum length can only be 15 this fits perfectly inside a >> nibble :) > > Except for flags to indicate absolute vs relative :) 0 1 2 3 4 5 6 7 8 9 a b c d e f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MinDig |MaxDig |F|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Anything else? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 02:13:21 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240693A6883; Fri, 18 Jul 2008 02:13:21 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97943A6813 for ; Fri, 18 Jul 2008 02:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYWftvYqFOcK for ; Fri, 18 Jul 2008 02:13:19 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 986983A6883 for ; Fri, 18 Jul 2008 02:13:16 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 23547A9348; Fri, 18 Jul 2008 10:13:48 +0100 (BST) Message-Id: From: Lawrence Conroy To: Richard Shockey In-Reply-To: <01d301c8e839$36496a20$a2dc3e60$@us> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 10:13:47 +0100 References: <195701c8e5eb$ad62d5b0$08288110$@us> <01d301c8e839$36496a20$a2dc3e60$@us> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-timms-encrypt-naptr-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, Speaking on behalf of Jim (who's still out to lunch) ... The draft describes what it does, how it does it, what is the use case (& implicitly the trade-offs) and what the initial security issues that have been considered. The goal here is to share data with some but not others using the DNS, but ->without requiring the whole of the Internet to change<-. Thus it is quite different from some of the other drafts - it's scope is *much* narrower and is firmly in ENUM space only. I don't believe that Jim expected to have a slot on the agenda this time. If you would like a quick summary on it in the meeting, then that's fine, but... It would be good if people could read the draft first. BTW, the encrypt-naptr scheme is in use already; this spec is intended as Experimental (hence the 'x-'). The basic Enumservice registration should be fairly straightforward - only question is how it fits with the new framework, and whether or not it needs the X- process in place or not to go through the IETF process. all the best Lawrence On 17 Jul 2008, at 19:15, Richard Shockey wrote: > Is this an agenda item?????? > >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Monday, July 14, 2008 3:00 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-timms-encrypt-naptr-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IANA Registration for Encrypted ENUM >> Author(s) : B. Timms, J. Reid, J. Schlyter >> Filename : draft-timms-encrypt-naptr-01.txt >> Pages : 21 >> Date : 2008-7-12 >> >> This document requests IANA registration of the "X-Crypto" >> Enumservice. This Enumservice indicates that its NAPTR holds a >> Uniform Resource Identifier that carries encrypted content from >> the >> fields of another (unpublished) Protected NAPTR, for use in E.164 >> Number Mapping (ENUM). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 02:40:50 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC46B3A6957; Fri, 18 Jul 2008 02:40:50 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486C73A6957 for ; Fri, 18 Jul 2008 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKSevEXjTBGL for ; Fri, 18 Jul 2008 02:40:48 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id BDE1E3A67C1 for ; Fri, 18 Jul 2008 02:40:47 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=pyk/+CfcEF8iyeD2oS98SLSED9oYcXtHcjug/n523LqyUrylVIvTSpum yqWW2FCCaldDqSRrNYIO+6uIq35RbA1Mxp8w9h21HL5bMmxJOxDFKk70S zMqpM+DeYRZVDtc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216374081; x=1247910081; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Fri,=2018=20Jul=202008=2010:41:18=20+0100 |Message-ID:=20|To:=20Duane=20|Cc:=20enum@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<48805C7B.8090303@e164.org>; bh=F4DKU+iC6SWIr13g+FVLiGQmiu5xH4s6xSrZB/i0UOY=; b=J9th8LXKdop5p0ZaYHyWdd99T8EUdA2xCB3f4hIYz/xGL8iWi3Zsn77w Gk17B+RXFcJUnUPl5DQY0FtGAMf9PnJVDbfy3K+kbHkDAZZ7UdDk3DLIc FWf6Y34kiXqAv+o; X-IronPort-AV: E=Sophos;i="4.31,209,1215385200"; d="scan'208";a="4198532" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Jul 2008 10:41:19 +0100 In-Reply-To: <48805C7B.8090303@e164.org> To: Duane MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 18 Jul 2008 10:41:18 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/07/2008 10:41:19 AM, Serialize complete at 18/07/2008 10:41:19 AM Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > You use the new DNS RR in the same way(s) you are proposing to use a > NAPTR record. As I said in my previous email, a new RR type wouldn't > have all the regex/text processing overhead so using binary parsing > would speed things up considerably. Sory - I think you missed my point. With overlapped dialling, one would send a DNS query with QTYPE = NAPTR to see if a full ENUM record is available. With Send-N, the full record isn't available, but a Send-N NAPTR is returned in its place. This is the standard DNS behaviour, with no special processing required at either end and it's all done in one DNS request round-trip. If a different RRtype is used for Send-N, the DNS client receiving NOHOST for the QTYPE = NAPTR lookup would need to send a second DNS request with QTYPE = SENDN. That's specifically what we're trying to avoid. The alternative would be to send QTYPE = ANY, but that's definitely considered bad practice. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 02:43:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030783A67C1; Fri, 18 Jul 2008 02:43:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5303A680E for ; Fri, 18 Jul 2008 02:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCZcHbkmNGsi for ; Fri, 18 Jul 2008 02:43:31 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id DA0F23A67C1 for ; Fri, 18 Jul 2008 02:43:30 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 832BDA9379; Fri, 18 Jul 2008 10:44:01 +0100 (BST) Message-Id: <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> From: Lawrence Conroy To: Duane In-Reply-To: <48805C7B.8090303@e164.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 10:44:01 +0100 References: <48805C7B.8090303@e164.org> X-Mailer: Apple Mail (2.926) Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Duane, What Ray has raised (and is not addressed by your mails) is why this is a NAPTR. It's like this because the client makes one query - for DNS type 35 - and gets back not only this one but also any Send-N answers. Thus, if the client has the correct number of digits already (e.g. the end user has an en-bloc phone and has entered the full number before hitting the send button), the final answer comes out with a single query. Thus for that [common] case, there is NO DNS QUERY OVERHEAD at all. That feature is more than good - it's crucial if this is deployed in a real telecom net. DNS scales, but elapsed time is still important. ---- I am puzzled, however, by this long and peregrinating thread. There is one question that seems to have been missed - does this need to be an E2U NAPTR, or instead could it use another DDDS Application (i.e. use a different collision-avoidance string)? There is nothing in 3761 (or 3761bis) that says that E2U NAPTRs are the only ones that can appear in a domain under e164.arpa. If this were another DDDS Application, any Send-N will come back in the same DNS response to a type 35 question. There would continue to be no overhead for the en bloc case. There would, however, be more flexibility, instead of being constrained with a comedy URI. Public ENUM clients will automatically discard any such NAPTR in the RRSet as it doesn't have the right collision-avoidance string (E2U) -- assuming that the client is not totally broken. So... what's wrong with moving this (and maybe other PSTN-internal meta-information specifications) into their own DDDS Application? all the best, Lawrence On 18 Jul 2008, at 10:03, Duane wrote: > Ray.Bellis@nominet.org.uk wrote: > >> If someone can propose a way to use a new RR-type which works with an >> optimal number of packets (i.e. 1) rather than size of packets then >> I'm >> open to it. > > You use the new DNS RR in the same way(s) you are proposing to use a > NAPTR record. As I said in my previous email, a new RR type wouldn't > have all the regex/text processing overhead so using binary parsing > would speed things up considerably. > >>> DNS Type SENDN ID to be assigned by IANA, packet structure: >>> >>> 0 1 2 3 4 5 6 7 >>> +-+-+-+-+-+-+-+-+ >>> |MinDig |MaxDig | >>> +-+-+-+-+-+-+-+-+ >>> >>> Since the maximum length can only be 15 this fits perfectly inside a >>> nibble :) >> >> Except for flags to indicate absolute vs relative :) > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |MinDig |MaxDig |F|0|0|0|0|0|0|0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Anything else? > > -- > > Best regards, > Duane > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 03:18:35 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305DC3A68DC; Fri, 18 Jul 2008 03:18:35 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB83A68C7 for ; Fri, 18 Jul 2008 03:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbmaL3LTfnRf for ; Fri, 18 Jul 2008 03:18:33 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 1E96E3A690A for ; Fri, 18 Jul 2008 03:18:33 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 97DBEA93B3; Fri, 18 Jul 2008 11:19:05 +0100 (BST) Message-Id: <94EA5BEE-CFA8-47F3-BE49-E6FF570CC051@insensate.co.uk> From: Lawrence Conroy To: Ray.Bellis@nominet.org.uk In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 11:19:05 +0100 References: X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org, Duane Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Ray, folks, Quick point - "QTYPE = ANY" is not an alternative (other than to sanity). "ANYthing you have lying around right now" is not what you want (ever). all the best, Lawrence On 18 Jul 2008, at 10:41, Ray.Bellis@nominet.org.uk wrote: > The alternative would be to send QTYPE = ANY, but that's definitely > considered bad practice. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 04:13:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09733A68D5; Fri, 18 Jul 2008 04:13:53 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9ABA3A69BB for ; Fri, 18 Jul 2008 04:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9-yg7C9ocgM for ; Fri, 18 Jul 2008 04:13:51 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 299893A68D5 for ; Fri, 18 Jul 2008 04:13:51 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id CA7A1FF270 for ; Fri, 18 Jul 2008 21:14:23 +1000 (EST) Message-ID: <48807A67.1060802@e164.org> Date: Fri, 18 Jul 2008 21:11:35 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: > With overlapped dialling, one would send a DNS query with QTYPE = NAPTR to > see if a full ENUM record is available. > > With Send-N, the full record isn't available, but a Send-N NAPTR is > returned in its place. This is the standard DNS behaviour, with no > special processing required at either end and it's all done in one DNS > request round-trip. > > If a different RRtype is used for Send-N, the DNS client receiving NOHOST > for the QTYPE = NAPTR lookup would need to send a second DNS request with > QTYPE = SENDN. That's specifically what we're trying to avoid. Then go with the additional records suggestion then, since you more than likely will have to poll 2 separate databases, what exactly is wrong with returning this information as either a pseudo RR like EDNS0 or something to that effect? Actually that would be the smart way to do it, the client sends a EDNS0 requests or something similar asking for send-n too, otherwise only NAPTR records are returned. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 04:54:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C753F28C0E0; Fri, 18 Jul 2008 04:54:45 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D2D28C0EC for ; Fri, 18 Jul 2008 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwGRn9j-7OTt for ; Fri, 18 Jul 2008 04:54:43 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 64E4828C0E3 for ; Fri, 18 Jul 2008 04:54:43 -0700 (PDT) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 17887A93FC; Fri, 18 Jul 2008 12:55:16 +0100 (BST) Message-Id: <63984C71-D628-424A-ABF6-3DC705F61E60@insensate.co.uk> From: Lawrence Conroy To: Duane In-Reply-To: <48807A67.1060802@e164.org> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 18 Jul 2008 12:55:15 +0100 References: <48807A67.1060802@e164.org> X-Mailer: Apple Mail (2.926) Cc: "enum@ietf.org" Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Duane, folks, I know it's friday afternoon, but is it strictly necessary to re-write DNS (by requiring new pseudo-opts in DNS messages) to do Number Port? First we have ANY, now we have new pseudo-opts. Please consider the LEAST change that will work efficiently *first*, not jump straight to something that needs the world to change. all the best, Lawrence [envious, as he obviously hasn't had the same number of beers at lunch :] On 18 Jul 2008, at 12:11, Duane wrote: > what exactly is wrong > with returning this information as either a pseudo RR like EDNS0 or > something to that effect? _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 04:57:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA4C3A69EA; Fri, 18 Jul 2008 04:57:53 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585E43A69C2 for ; Fri, 18 Jul 2008 04:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEFqkcDU7TQK for ; Fri, 18 Jul 2008 04:57:51 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 980393A6816 for ; Fri, 18 Jul 2008 04:57:51 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 4DE1BFF270; Fri, 18 Jul 2008 21:58:24 +1000 (EST) Message-ID: <488084B9.8060509@e164.org> Date: Fri, 18 Jul 2008 21:55:37 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Lawrence Conroy References: <48807A67.1060802@e164.org> <63984C71-D628-424A-ABF6-3DC705F61E60@insensate.co.uk> In-Reply-To: <63984C71-D628-424A-ABF6-3DC705F61E60@insensate.co.uk> X-Enigmail-Version: 0.95.0 Cc: "enum@ietf.org" Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence Conroy wrote: > Hi Duane, folks, > I know it's friday afternoon, but is it strictly necessary to re-write > DNS (by requiring new pseudo-opts in DNS messages) to do Number Port? > First we have ANY, now we have new pseudo-opts. > Please consider the LEAST change that will work efficiently *first*, > not jump straight to something that needs the world to change. Actually it's Friday night here, that aside the world isn't changing, the send-n folks are trying to change it by breaking wild cards and causing looping in certain situations. So when it comes down to the crux of it, you'd rather do a quick hack than do it properly? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 05:10:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3DF3A6953; Fri, 18 Jul 2008 05:10:19 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186C53A6953 for ; Fri, 18 Jul 2008 05:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmNU1fQNAMf3 for ; Fri, 18 Jul 2008 05:10:17 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 2080B3A67C0 for ; Fri, 18 Jul 2008 05:10:16 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6ICAkNR020921Fri, 18 Jul 2008 12:10:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KJonO-000PrP-00; Fri, 18 Jul 2008 13:10:46 +0100 Date: Fri, 18 Jul 2008 13:10:46 +0100 From: "Clive D.W. Feather" To: Duane Message-ID: <20080718121045.GH80117@finch-staff-1.thus.net> References: <48807A67.1060802@e164.org> <63984C71-D628-424A-ABF6-3DC705F61E60@insensate.co.uk> <488084B9.8060509@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <488084B9.8060509@e164.org> User-Agent: Mutt/1.5.3i Cc: "enum@ietf.org" , Lawrence Conroy Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Duane said: > Actually it's Friday night here, that aside the world isn't changing, > the send-n folks are trying to change it by breaking wild cards and > causing looping in certain situations. Neither of these is the case. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 05:11:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A21F3A67D1; Fri, 18 Jul 2008 05:11:53 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3713A67D1 for ; Fri, 18 Jul 2008 05:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkHNSjp0rSSf for ; Fri, 18 Jul 2008 05:11:52 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id AA7E73A67C0 for ; Fri, 18 Jul 2008 05:11:51 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m6ICCM2o023302Fri, 18 Jul 2008 12:12:22 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1KJoov-000PsQ-00; Fri, 18 Jul 2008 13:12:21 +0100 Date: Fri, 18 Jul 2008 13:12:21 +0100 From: "Clive D.W. Feather" To: Lawrence Conroy Message-ID: <20080718121221.GI80117@finch-staff-1.thus.net> References: <48805C7B.8090303@e164.org> <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> User-Agent: Mutt/1.5.3i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, Duane Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence Conroy said: > Thus for that [common] case, there is NO DNS QUERY OVERHEAD at all. > That feature is more than good - it's crucial if this is deployed > in a real telecom net. DNS scales, but elapsed time is still important. Right. > I am puzzled, however, by this long and peregrinating thread. > There is one question that seems to have been missed - does this need > to be an E2U NAPTR, or instead could it use another DDDS Application > (i.e. use a different collision-avoidance string)? I don't see any particular thing that requires E2U. > So... what's wrong with moving this (and maybe other PSTN-internal > meta-information specifications) into their own DDDS Application? Apart from the amount of I-D writing, nothing that I can see. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 05:47:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CB23A6893; Fri, 18 Jul 2008 05:47:12 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28813A6893 for ; Fri, 18 Jul 2008 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id insajMZ0Oy30 for ; Fri, 18 Jul 2008 05:47:10 -0700 (PDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by core3.amsl.com (Postfix) with ESMTP id B0B673A6816 for ; Fri, 18 Jul 2008 05:47:09 -0700 (PDT) Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1KJpN7-0002ek-1Y for enum@ietf.org; Fri, 18 Jul 2008 13:47:41 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out5.blueyonder.co.uk with esmtp (Exim 4.52) id 1KJpN5-0001ZC-KA for enum@ietf.org; Fri, 18 Jul 2008 13:47:39 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 954A41C963F2 for ; Fri, 18 Jul 2008 13:47:38 +0100 (BST) Message-Id: From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Jul 2008 13:47:38 +0100 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 18 Jul 2008, at 10:41, Ray.Bellis@nominet.org.uk wrote: >> You use the new DNS RR in the same way(s) you are proposing to use a >> NAPTR record. As I said in my previous email, a new RR type wouldn't >> have all the regex/text processing overhead so using binary parsing >> would speed things up considerably. > > Sory - I think you missed my point. > > With overlapped dialling, one would send a DNS query with QTYPE = > NAPTR to > see if a full ENUM record is available. > > With Send-N, the full record isn't available, but a Send-N NAPTR is > returned in its place. This is the standard DNS behaviour, with no > special processing required at either end and it's all done in one DNS > request round-trip. I interpreted his comment to mean 'no regular expression processing' as obviously this has a processing cost. Perhaps using an S-NAPTR style scheme with static data might alleviate this? > If a different RRtype is used for Send-N, the DNS client receiving > NOHOST > for the QTYPE = NAPTR lookup would need to send a second DNS request > with > QTYPE = SENDN. That's specifically what we're trying to avoid. Indeed latency will be the single biggest cost, especially for mobile devices. It's all too easy to forget this. Of course there's no reason why the client can't send two DNS requests at the same time, one for NAPTRs and one for another RRTYPE, then act depending on which brings back a meaningful result, but this of course would double the number of requests to be handled by the DNS server relative to the number of ENUM queries required. > The alternative would be to send QTYPE = ANY, but that's definitely > considered bad practice. Although in this particular instance it might be appropriate... Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net http://www.linkedin.com/in/eleanormchugh _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 06:34:17 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612E43A6A1C; Fri, 18 Jul 2008 06:34:17 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBB13A698D for ; Fri, 18 Jul 2008 06:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL-zwn1ZMuy1 for ; Fri, 18 Jul 2008 06:34:14 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 9C4403A6A1C for ; Fri, 18 Jul 2008 06:34:14 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=LYpLNGaTpFilyhYkoKJNs+VobgmAUlzWmMR4v4MaMGfIMZEZbMBaRDcF OBOSk8NBsK0K7xPkqLG3KXjp9a/Ko2kS4uPCen0DdR3CUn3wNkUc9CHVl BYYFb5wBEZ7NBnZ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216388088; x=1247924088; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Fri,=2018=20Jul=202008=2014:34:45=20+0100 |Message-ID:=20|To:=20Lawrence=20Conroy =20|Cc:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<94EA5BEE-CFA8-47F3-B E49-E6FF570CC051@insensate.co.uk>; bh=XYzuc3gZ/6sZI6O6gXg1BgfSZQ4fdW59oGYL5kFy3Ag=; b=ghhubNCpRYTy3Pw9FPyXaEbNujQMnngmjx4aPYbtWgKTLHUoXoeRPobE z2r8aWDAU7026DW0JES3eqNWrGgly25/Xf9IYh/1j6RU7mwzhyDWPP34H lyuorQiOAQPYVCF; X-IronPort-AV: E=Sophos;i="4.31,210,1215385200"; d="scan'208";a="4204214" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Jul 2008 14:34:46 +0100 In-Reply-To: <94EA5BEE-CFA8-47F3-BE49-E6FF570CC051@insensate.co.uk> To: Lawrence Conroy MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 18 Jul 2008 14:34:45 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/07/2008 02:34:46 PM, Serialize complete at 18/07/2008 02:34:46 PM Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Hi Ray, folks, > Quick point - "QTYPE = ANY" is not an alternative (other than to > sanity). > "ANYthing you have lying around right now" is not what you want (ever). > all the best, That's what I meant - QTYPE = ANY is a theoretical solution, but you wouldn't want to do it. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 06:55:09 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372693A69B4; Fri, 18 Jul 2008 06:55:09 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988FD28C135 for ; Fri, 18 Jul 2008 06:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 347QXZkwmdxz for ; Fri, 18 Jul 2008 06:55:07 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 4D88928C104 for ; Fri, 18 Jul 2008 06:55:06 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=YOzsxA+dJfge6RUX1UOLZhhGkex1aXk8yHomm0fXaAOUFdcFdsiTzxEs e2mSl3esMCOmaxo2SCwxMFzEXnrhAE/PFe/1P9JLsPgTEeNn1zFwAZshd 9v7yjvZHXfosmx1; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216389341; x=1247925341; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Fri,=2018=20Jul=202008=2014:55:38=20+0100 |Message-ID:=20|To:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<35D626BA-1D47-4A1A-9 B88-81412E27E818@insensate.co.uk>; bh=j7aaMkL6FKwGRcSmx6b7S1Rh1K8gIrkvYVGS5rTaxdc=; b=OuXwrWJ+rUmJvboKe2VYfii1t0LkQSULJqFrvkeiIucoow5DMlDc+4kk +RKD0O8Um8q41ODLDHBzNn017e8+gMI3jyorZagcet8fs0zk/Ba4rRZcv rdxYKgy/Wno2Haq; X-IronPort-AV: E=Sophos;i="4.31,210,1215385200"; d="scan'208";a="4204654" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Jul 2008 14:55:39 +0100 In-Reply-To: <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 18 Jul 2008 14:55:38 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/07/2008 02:55:39 PM, Serialize complete at 18/07/2008 02:55:39 PM Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I am puzzled, however, by this long and peregrinating thread. > There is one question that seems to have been missed - does this need > to be an E2U NAPTR, or instead could it use another DDDS Application > (i.e. use a different collision-avoidance string)? That's a very interesting question, and one I don't have an obvious answer for. Peter Koch said that Send-N isn't actually an ENUM Service, and technically he is of course correct. > There is nothing in 3761 (or 3761bis) that says that E2U NAPTRs are > the only ones that can appear in a domain under e164.arpa. > If this were another DDDS Application, any Send-N will come back in > the same DNS response to a type 35 question. There would continue to > be no overhead for the en bloc case. There is certainly some sense in clients being able to filter by type rather than subtype, particularly as the processes for filtering and ordering based on subtype are less than crystal clear. If I have any niggle with the idea it's that this would effectively interleave two separate DDDS applications in one DNS lookup. That doesn't really bother me, although I can imagine some might object. > There would, however, be more flexibility, instead of being constrained > with a comedy URI. Public ENUM clients will automatically discard any > such NAPTR in the RRSet as it doesn't have the right collision-avoidance > string (E2U) -- assuming that the client is not totally broken. > > So... what's wrong with moving this (and maybe other PSTN-internal > meta-information specifications) into their own DDDS Application? For reasons already outlined it would still need to be a DDDS NAPTR, and therefore it would still need to use the regexp rewrite fiel. I'm not convinced that it would make sense to radically alter the currently proposed Send-N URI format, particularly if Send-N is just one of a set of future meta-data types. Richard - what plans (if any) do you have for your CNAM draft? Obviously I've borrowed heavily from that for my URI syntax. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jul 18 09:06:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30C93A6839; Fri, 18 Jul 2008 09:06:24 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA20D28C199 for ; Fri, 18 Jul 2008 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxWajdQ5kIZc for ; Fri, 18 Jul 2008 09:06:22 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id C20283A6839 for ; Fri, 18 Jul 2008 09:06:21 -0700 (PDT) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6IG2Evk020952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Jul 2008 09:02:31 -0700 From: "Richard Shockey" To: Date: Fri, 18 Jul 2008 12:03:04 -0400 Message-ID: <013501c8e8ef$d6f6deb0$84e49c10$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjo78K3itjTOih8QL6e+/STVxbwGQ== Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] Almost Final ENUM Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org IETF 72 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 5 M The following 3 drafts will be discussed consecutively. 20 M 2. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-10.txt Pages : 40 Date : 2008-05-19 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-10.tx t 3. Title : Update of legacy IANA Registrations of Enumservices Author(s) : B. Hoeneisen, A. Mayrhofer Filename : draft-hoeneisen-enum-enumservices-transition-01.txt Pages : 21 Date : 2008-05-20 This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-enumservices-transi tion-01.txt 4. Title : IANA Registration of Experimental and Trial Enumservices (X-Enumservices) Author(s) : B. Hoeneisen Filename : draft-ietf-enum-x-service-regs-01.txt Pages : 15 Date : 2008-05-21 This document specifies a new IANA registry for experimental and trial Enumservices (X-Enumservices), describes corresponding registration procedures, and provides a guideline for creating X-Enumservices and its Registration Documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-x-service-regs-01.txt New ENUMservices... we need a quick discussion here leading to WG humm on action as WG items. 10 M 5. Title : IANA Registration for Location ('loc') Enumservice Author(s) : A. Mayrhofer Filename : draft-mayrhofer-enum-loc-enumservice-00.txt Pages : 9 Date : 2008-06-19 This document requests IANA registration of an Enumservice for reflecting location information. The Enumservice uses the 'loc' Type name, and makes use of the proposed 'held' and 'geo' URI schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-loc-enumservice-00. txt The following draft is ultimately targeted for Experimental we need to decide if we let this go through now our wait for the X-Services draft. 5a. Title : IANA Registration for Encrypted ENUM Author(s) : B. Timms, J. Reid, J. Schlyter Filename : draft-timms-encrypt-naptr-01.txt Pages : 21 Date : 2008-7-12 This document requests IANA registration of the "X-Crypto" Enumservice. This Enumservice indicates that its NAPTR holds a Uniform Resource Identifier that carries encrypted content from the fields of another (unpublished) Protected NAPTR, for use in E.164 Number Mapping (ENUM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt Main Event.. 15 Min +++ 6. Title : IANA Registrations for the 'Send-N' Enumservice Author(s) : R. Bellis Filename : draft-bellis-enum-send-n-02.txt Pages : 11 Date : 2008-06-23 This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-02.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jul 19 21:21:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3FD3A6873; Sat, 19 Jul 2008 21:21:53 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2CD3A693D for ; Sat, 19 Jul 2008 21:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpir9F2RbLg2 for ; Sat, 19 Jul 2008 21:21:51 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id A640E3A681C for ; Sat, 19 Jul 2008 21:21:51 -0700 (PDT) Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 3B8C6FF26C; Sun, 20 Jul 2008 14:22:29 +1000 (EST) Message-ID: <4882BCC8.9030503@e164.org> Date: Sun, 20 Jul 2008 14:19:20 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: In-Reply-To: X-Enigmail-Version: 0.95.0 Cc: enum@ietf.org Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ray.Bellis@nominet.org.uk wrote: > For reasons already outlined it would still need to be a DDDS NAPTR, and > therefore it would still need to use the regexp rewrite fiel. I'm not > convinced that it would make sense to radically alter the currently > proposed Send-N URI format, particularly if Send-N is just one of a set of > future meta-data types. I'm pretty sure it was you that made the comment about the DNS software you're using is custom written, it would be almost silly to pre-populate a database with all the possible combinations when most are the same etc. Someone else, maybe it was you mentioned this was meta information, your reasoning for keeping this in NAPTR space is to reduce lookups, fair enough, so still do it under a new RR type, and return this in the additional section along with NAPTR records in the answer section. If you aren't going to pre-populate a DNS database (like BIND) then where is the issue with sticking it under some other RR type? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 20 01:17:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED1B3A690B; Sun, 20 Jul 2008 01:17:26 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB08A3A68F2 for ; Sun, 20 Jul 2008 01:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmhQzVtFH+eg for ; Sun, 20 Jul 2008 01:17:25 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B573D3A6858 for ; Sun, 20 Jul 2008 01:17:24 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=JOAayTa/wRl9bMQDNTDMucex109AfVNaNIR12SN8PQ/4XCdodEtb7yAQ qlSytP1fT5gQ8as1zRJBtIDrzShDCUOzcSuRgF4GccxxGKg35YVV6I/wd sDkyEyLzmEXa+qO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216541882; x=1248077882; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20Send-N=20draft:=20draft-bellis-enum-send-n-02=20publi shed|Date:=20Sun,=2020=20Jul=202008=2009:17:58=20+0100 |Message-ID:=20|To:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<4882BCC8.9030503@e16 4.org>; bh=RP7usdtFK0ELGzE05SPAjKjdF06w/oLX5gwnpaAJG9U=; b=HsTpxgcHbSO6kzE4hjh+VSJPFYJWtbEDpRbvMYFd7IGxitI0NQtmmw0y DkcItvoimGfhovNC7qsHdTLPJ8wtJsdSEa05/YzTwiNuUq40mjQMzgPAT xzonJeV9jKYtXcn; X-IronPort-AV: E=Sophos;i="4.31,217,1215385200"; d="scan'208";a="4244718" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Jul 2008 09:17:58 +0100 In-Reply-To: <4882BCC8.9030503@e164.org> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sun, 20 Jul 2008 09:17:58 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/07/2008 09:17:58 AM, Serialize complete at 20/07/2008 09:17:58 AM Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > I'm pretty sure it was you that made the comment about the DNS software > you're using is custom written, it would be almost silly to pre-populate > a database with all the possible combinations when most are the same etc. There are cases where the Send-N records could be completely automatically synthesised in real-time. In the UK case, however, each carrier is expecting to secondary significant portions of the database into their own DNS servers. We don't expect those carriers to perform the same synthesis, therefore the Send-N's are expeced to be pre-populated as real RRs in the zone file. They'll be available in IXFRs just like any other RR. > Someone else, maybe it was you mentioned this was meta information, your > reasoning for keeping this in NAPTR space is to reduce lookups, fair > enough, so still do it under a new RR type, and return this in the > additional section along with NAPTR records in the answer section. > > If you aren't going to pre-populate a DNS database (like BIND) then > where is the issue with sticking it under some other RR type? This idea of using the Additional Section and why it was rejected was mentioned a couple of days ago. There was a lot of concern from the WG as to whether Send-N would change any semantics of DNS (specifically wildcards, of course). IMHO, making a change which relies on non-standard behaviour in any server would do just that. The UK CDB operator may well use customised DNS server software, but its behaviour as currently proposed will look completely standard to the outside world. We also can't expect all of the carriers who are secondarying the zones to have to run customised DNS server software with special Additional Section handling. FWIW, I think Lawrence is onto something when he suggested a separate DDDS service (albeit in the same tree). I'd like to hear what others think of that. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 20 12:43:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57AF3A6A73; Sun, 20 Jul 2008 12:43:04 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC6F3A6A73 for ; Sun, 20 Jul 2008 12:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR3rhHxVAYS3 for ; Sun, 20 Jul 2008 12:43:03 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id E00E63A69B3 for ; Sun, 20 Jul 2008 12:43:02 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=fjT2KHzaoAGc9g4lYRIVRT5+LWcU4Pz0Q28bvehcgLU2jTQuqFwrNN28 hg0hoIe2RXHDVfSBb+ADn6JTkaPgTjtjiQj1JhRsseDjU2LK+/gGHZNET RAellABOiVICdy3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216583021; x=1248119021; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Re :=20[Enum]=20Send-N=20draft:=20draft-bellis-enum-send-n-0 2=20published|Date:=20Sun,=2020=20Jul=202008=2020:43:38 =20+0100|Message-ID:=20|To:=20Duane=20|Cc:=20enum@ietf.org,=0D=0A=09Ray.Bellis@no minet.org.uk|MIME-Version:=201.0|In-Reply-To:=20<4882BCC8 .9030503@e164.org>|References:=20=20<488 2BCC8.9030503@e164.org>; bh=6U96/70dZcYBR+jKhD/jRX5DXg0e+OHBWYcHsrwCWZQ=; b=4uF2LeVblnrmcF3SBtYTlcChSycELjEM1etkKt4wi1ZgK4GcJRUSYuW9 J3qCsF0cBxIjusk9aGHBWrZYOjwkB8ex6evHcVoLnD2JzjrI+NkRJBErj bqS+jWRxVQBokpI; X-IronPort-AV: E=Sophos;i="4.31,219,1215385200"; d="scan'208";a="4252887" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Jul 2008 20:43:39 +0100 In-Reply-To: <4882BCC8.9030503@e164.org> References: <4882BCC8.9030503@e164.org> To: Duane MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Sun, 20 Jul 2008 20:43:38 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/07/2008 08:43:39 PM, Serialize complete at 20/07/2008 08:43:39 PM Cc: enum@ietf.org, Ray.Bellis@nominet.org.uk Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Duane wrote on 20/07/2008 05:19:20: > If you aren't going to pre-populate a DNS database (like BIND) then > where is the issue with sticking it under some other RR type? 1. Because we only need it for ENUM. 2. Because the hierarchy of ownership of labels for ENUM is completely different from the hierarchy for ordinary DNS and in ordinary DNS it is not acceptable for the owner of one label to make authoritative statements about a lower label under different ownership. Not to mention the fact that this is the wrong place to discuss this - DNSEXT is the place for a new general RR. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jul 20 12:45:26 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB573A6A06; Sun, 20 Jul 2008 12:45:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF6F3A6A06 for ; Sun, 20 Jul 2008 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdWGI2-6UX+x for ; Sun, 20 Jul 2008 12:45:13 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 7B5DB3A69B3 for ; Sun, 20 Jul 2008 12:45:12 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=v+A8wB1lsTwki3HHxcH9NFtsLwq0B1YpHZjOuWGGrfb7a9DJstekEFhB lmg7WUwE/+l/cB2qpPmALo9ZRwEWSPmOeE2yq7Nblh6lT2FxM/GycWS4J stIeOF0ZqiR6yeo; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216583150; x=1248119150; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jay=20Daley=20|Subject:=20Re :=20[Enum]=20Send-N=20draft:=20draft-bellis-enum-send-n-0 2=20published|Date:=20Sun,=2020=20Jul=202008=2020:45:48 =20+0100|Message-ID:=20|To:=20Lawrence =20Conroy=20|Cc:=20enum@ietf.org ,=0D=0A=09Ray.Bellis@nominet.org.uk|MIME-Version:=201.0 |In-Reply-To:=20<35D626BA-1D47-4A1A-9B88-81412E27E818@ins ensate.co.uk>|References:=20=0D=0A=09<48 805C7B.8090303@e164.org>=20<35D626BA-1D47-4A1A-9B88-81412 E27E818@insensate.co.uk>; bh=R0wLq+jfeY5y3iCvaEsQoXVzg0E07tSmVYKp04TYtCI=; b=IXw3+PyEUkfpK364r1qv4VOp5SzMBEukjeLanvwmhxkweVNMB1oAsGjq bQHvLXjbjZ5HuqK+gc6bhB2aYif5Xe4+ddmoh5DyG19jNH0fIL0s3ZhyR UMS5s5BeE/Ioe3P; X-IronPort-AV: E=Sophos;i="4.31,219,1215385200"; d="scan'208";a="4252901" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Jul 2008 20:45:49 +0100 In-Reply-To: <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> References: <48805C7B.8090303@e164.org> <35D626BA-1D47-4A1A-9B88-81412E27E818@insensate.co.uk> To: Lawrence Conroy MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M1_05262008 May 26, 2008 Message-ID: From: Jay Daley Date: Sun, 20 Jul 2008 20:45:48 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/07/2008 08:45:49 PM, Serialize complete at 20/07/2008 08:45:49 PM Cc: enum@ietf.org, Ray.Bellis@nominet.org.uk Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence > So... what's wrong with moving this (and maybe other PSTN-internal > meta-information specifications) into their own DDDS Application? A very good idea. What else needs to be wrapped up in it other than send-n? Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 21 02:13:06 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15C93A6804; Mon, 21 Jul 2008 02:13:06 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF18A3A6804 for ; Mon, 21 Jul 2008 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhENEQHYgxJ7 for ; Mon, 21 Jul 2008 02:13:04 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id BC3933A6767 for ; Mon, 21 Jul 2008 02:13:03 -0700 (PDT) Received: from [10.10.0.113] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Mon, 21 Jul 2008 11:13:34 +0200 id 000000DD.4884533E.00000E7A Message-ID: <48845337.8020209@enum.at> Date: Mon, 21 Jul 2008 11:13:27 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: enum@ietf.org Subject: [Enum] Enumservices Guide - Road map X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Fellow WG members, as you know one of the major remaining items of the WG work is the = Enumservices Guide. We believe that this document is mature enough to go = into Lurking err.. Working Group Last Call (probably during or right = after the Dublin meeting) - it's likely not perfect, but the amount of = feedback we receive indicates the WG is happy with it as it is. What we'd like to do is the following: - Can you please do an in-depth review of the current draft (http://tools.ietf.org/id/draft-ietf-enum-enumservices-guide-10.txt). We'd appreciate if that review can be performed asap. Before we have three (3) persons that have told us they have done such a review we will not move the draft forward. - We've a list of open tickets/issues at http://ietf.enum.at/cgi-bin/trac.cgi/report/1 - We need someone that can go through them with "fresh eyes" and provide feedback on them (and yes, we know that there are some smaller and larger chunks). If you do, please let us know. We need at least one (1) person that have gone through the list in detail before we really trust the data. - Even though we've asked IANA for early feedback a while ago, all we got by now is a ticket number. We know this is a bit frustrating for all of us, but we won't receive any feedback until very late in the publication process. If anybody feels capable of doing a review from IANA-perspective, we'd definitely appreciate that. We are continuing our discussion with IANA. - We'd also like to know whether anybody thinks that document is _NOT_ = ready to go to WGLC. Patrik F=E4ltstr=F6m (WG chair) Richard Shockey (WG chair) Bernie H=F6neisen (Editor) Alex Mayrhofer (Editor) _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 22 12:21:26 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE8C3A6881; Tue, 22 Jul 2008 12:21:26 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBE83A6881 for ; Tue, 22 Jul 2008 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewqvoAUJMR22 for ; Tue, 22 Jul 2008 12:21:24 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 3285A3A67FF for ; Tue, 22 Jul 2008 12:21:24 -0700 (PDT) Received: from [195.54.233.69] (HELO gromit.rfc1035.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTP id 330613; Tue, 22 Jul 2008 20:22:03 +0100 Message-Id: <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> From: Jim Reid To: Jay Daley In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 22 Jul 2008 20:22:03 +0100 References: <4882BCC8.9030503@e164.org> X-Mailer: Apple Mail (2.926) Cc: enum@ietf.org, Ray.Bellis@nominet.org.uk, Duane Subject: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Apologies for using a meaningful Subject: header. Well someone had to make a start..... On 20 Jul 2008, at 20:43, Jay Daley wrote: > Duane wrote on 20/07/2008 05:19:20: > >> If you aren't going to pre-populate a DNS database (like BIND) then >> where is the issue with sticking it under some other RR type? > > 1. Because we only need it for ENUM. No, it's needed for a behind-closed-doors version of 4.4.e164.arpa. > 2. Because the hierarchy of ownership of labels for ENUM is > completely > different from the hierarchy for ordinary DNS Rubbish. The DNS has never, ever cared about "ownership of labels" whatever that means. A client does a lookup and gets a response. It doesn't have the slightest interest in who "owns" the label or operates the name servers for it. > and in ordinary DNS it is > not acceptable for the owner of one label to make authoritative > statements > about a lower label under different ownership. Aha! I suppose you mean delegation points and zone cuts. Well what you say is true up to a point: though our DNSSEC friends have done a good job of demolishing that. DS records, anyone? Even so, your point Jay is a diversion. IIUC, there won't be delegations in this behind-closed-doors version of 4.4.e164.arpa. This list has been told about a monolithic name space, database driven DNS records and even responses being generated on the fly. This doesn't look anything like a conventional delegation model where longer labels are handed out to distinct "owners". Or am I missing something? > Not to mention the fact that this is the wrong place to discuss this - > DNSEXT is the place for a new general RR. Indeed. This is why I privately suggested to Ray that he replace send- n with a new RRtype template that should sail through the 2929-bis process. Aside from all the heat that's being generated here, I think send-n is in trouble because it does not define a URI. I'm still far from convinced about the alleged benefits of saving the odd DNS lookup: the latency is one valid point, but some extra queries, so what? The resolving entities will presumably acquire a rich cache very quickly, _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 22 14:44:37 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1953A3A69BA; Tue, 22 Jul 2008 14:44:37 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04103A69A4 for ; Tue, 22 Jul 2008 14:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvKgzaYyW8e0 for ; Tue, 22 Jul 2008 14:44:35 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B15C03A6818 for ; Tue, 22 Jul 2008 14:44:34 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8896924; Tue, 22 Jul 2008 17:44:45 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 17:44:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:44:15 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602045CBFC8@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <48845337.8020209@enum.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Enumservices Guide - Road map Thread-Index: AcjrEiNQ6m12nF02SRebpZZFq5sLjABMd2VQ References: <48845337.8020209@enum.at> From: "Livingood, Jason" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 22 Jul 2008 21:44:44.0606 (UTC) FILETIME=[2794E5E0:01C8EC44] Subject: Re: [Enum] Enumservices Guide - Road map X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I will review it again, having been away from the draft since Philadelphia.= I will also go through all the open tickets. Jason = > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On = > Behalf Of Alexander Mayrhofer > Sent: Monday, July 21, 2008 5:13 AM > To: enum@ietf.org > Subject: [Enum] Enumservices Guide - Road map > = > = > Fellow WG members, > = > as you know one of the major remaining items of the WG work = > is the Enumservices Guide. We believe that this document is = > mature enough to go into Lurking err.. Working Group Last = > Call (probably during or right after the Dublin meeting) - = > it's likely not perfect, but the amount of feedback we = > receive indicates the WG is happy with it as it is. > = > What we'd like to do is the following: > = > = > - Can you please do an in-depth review of the current draft = > (http://tools.ietf.org/id/draft-ietf-enum-enumservices-guide-10.txt). > We'd appreciate if that review can be performed asap. Before = > we have three (3) persons that have told us they have done = > such a review we will not move the draft forward. > = > - We've a list of open tickets/issues at > http://ietf.enum.at/cgi-bin/trac.cgi/report/1 - We need = > someone that can go through them with "fresh eyes" and = > provide feedback on them (and yes, we know that there are = > some smaller and larger chunks). > If you do, please let us know. We need at least one (1) = > person that have gone through the list in detail before we = > really trust the data. > = > - Even though we've asked IANA for early feedback a while = > ago, all we got by now is a ticket number. We know this is a = > bit frustrating for all of us, but we won't receive any = > feedback until very late in the publication process. If = > anybody feels capable of doing a review from = > IANA-perspective, we'd definitely appreciate that. We are = > continuing our discussion with IANA. > = > - We'd also like to know whether anybody thinks that document = > is _NOT_ ready to go to WGLC. > = > = > Patrik F=E4ltstr=F6m (WG chair) > Richard Shockey (WG chair) > Bernie H=F6neisen (Editor) > Alex Mayrhofer (Editor) > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > = _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum@listserver.internetnz.net.nz Tue Jul 22 16:55:12 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D700828C13F for ; Tue, 22 Jul 2008 16:55:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -6.726 X-Spam-Level: X-Spam-Status: No, score=-6.726 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUVWxSFi5MYN for ; Tue, 22 Jul 2008 16:55:12 -0700 (PDT) Received: from c-76-110-143-7.hsd1.fl.comcast.net (c-76-110-143-7.hsd1.fl.comcast.net [76.110.143.7]) by core3.amsl.com (Postfix) with SMTP id BE4CC28C13B for ; Tue, 22 Jul 2008 16:55:10 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 14717 by uid 345); Tue, 22 Jul 2008 07:55:38 -0500 Message-Id: <20080722025538.14719.qmail@c-76-110-143-7.hsd1.fl.comcast.net> To: Subject: Three Days Only! Extra 25% Off. Details Inside. From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Tue, 22 Jul 2008 16:55:10 -0700 (PDT) Victoria's Secret
Must-Have Looks For Summer. If you are unable to see the images in this email, please click here.
Catalogue Quick Order Forward to a Friend



SPECIAL OFFER DETAILS:
*Easy Monthly Payments *No Risk 30-Day Money Back Guarantee

This special offer is available for only 3 days. Discounts are included in final prices.


You are receiving this email because you have subscribed to the Pharmacy® newsletter with the following address: enum-archive@ietf.org.

Unsubscribe | Privacy policy | Contact us

© 2008 Pharmacy All rights reserved.
From enum-bounces@ietf.org Wed Jul 23 01:59:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58B33A6AE2; Wed, 23 Jul 2008 01:59:18 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E6A28C0E8 for ; Wed, 23 Jul 2008 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjJl3cBR-nuC for ; Wed, 23 Jul 2008 01:59:17 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 049EB3A6ACD for ; Wed, 23 Jul 2008 01:59:16 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=VsDROXbA3f2CGXcoKPA5D8CEF3IL2o5+ozN+w8u49Lz9aY0nUhlCG+dM XvgBk3gOttt0plXO0HEU7+4N1yR4KOFOBthPkfxiyFp5TcW/LzJRTgtdX MbfcNKTiP+jwlDK; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=jay@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216803600; x=1248339600; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Jay=20Daley"=20|Subject:=20 Re:=20a=20new=20RRype=20instead=20of=20send-n=20NAPTRs |Date:=20Wed,=2023=20Jul=202008=2009:59:28=20+0100 |Message-ID:=20|To:=20Jim=20Reid=20|Cc:=20enum@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc 1035.com>|References:=20=20<4882BCC8.903 0503@e164.org>=20=20<10B101C6-EFC4-4388- 8E29-97CBBC6891FB@rfc1035.com>; bh=RK6IfB+fgypMt1/dDrRC6tXPZXB57rOriCQlQ9vMx6Q=; b=ocgu7REtuyM1dwulcUMn0PSxp8d8YM1VjIdDhZ2Ku301G3xkgxz+gFIb vPj4a3nZ6E3gPcGD0UPVkDBuXuzYtB5aT/J3l/d1Uq9HWxZn2jGFLRXFN 0pK4Ly35VM4uTYf; X-IronPort-AV: E=Sophos;i="4.31,237,1215385200"; d="scan'208";a="4305226" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 23 Jul 2008 09:59:58 +0100 In-Reply-To: <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> References: <4882BCC8.9030503@e164.org> <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> To: Jim Reid MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Jay Daley" Date: Wed, 23 Jul 2008 09:59:28 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/07/2008 09:59:57 AM, Serialize complete at 23/07/2008 09:59:57 AM Cc: enum@ietf.org Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Jim Reid wrote on 22/07/2008 20:22:03: > Rubbish. The DNS has never, ever cared about "ownership of labels" > whatever that means. A client does a lookup and gets a response. It > doesn't have the slightest interest in who "owns" the label or > operates the name servers for it. I'm sure you know this, but just in case ... in DNS a parent never makes an authoritative statement about a child's data. If you have a new RR Type like this that can apply to any part of DNS then it will allow a (grand)parent to make an authoritative statement about a (grand)child's data. > Aha! I suppose you mean delegation points and zone cuts. Well what you > say is true up to a point: though our DNSSEC friends have done a good > job of demolishing that. DS records, anyone? Sorry. maybe you do know it. > Even so, your point Jay is a diversion. IIUC, there won't be > delegations in this behind-closed-doors version of 4.4.e164.arpa. This > list has been told about a monolithic name space, database driven DNS > records and even responses being generated on the fly. This doesn't > look anything like a conventional delegation model where longer labels > are handed out to distinct "owners". Or am I missing something? Yes you are missing something - the whole point from what I can see. In many instances of ENUM it is acceptable for a parent to make an authoritative statement about a child. So that's why doing this for ENUM is acceptable, whereas a new RR type is not. > Indeed. This is why I privately suggested to Ray that he replace send- > n with a new RRtype template that should sail through the 2929-bis > process. 'sail through' - you're having a laugh! > Aside from all the heat that's being generated here, I think send-n is > in trouble because it does not define a URI. I'm still far from > convinced about the alleged benefits of saving the odd DNS lookup: the > latency is one valid point, but some extra queries, so what? The > resolving entities will presumably acquire a rich cache very quickly, In the telephony world there is increasing pressure towards changes of routing (such as porting) to be reflected very quickly. Mainly to avoid circular routing or failed calls. So caching is much less a useful tool than you might imagine. So what do you think of Lawrence's sensible suggestion of making pstn/numbering meta-data into a new DDDS application - equally dismissive? Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 23 04:03:36 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6BD3A6A22; Wed, 23 Jul 2008 04:03:36 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95ED228C180 for ; Wed, 23 Jul 2008 04:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRMw4oW-0CbU for ; Wed, 23 Jul 2008 04:03:34 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 73A0B3A6805 for ; Wed, 23 Jul 2008 04:03:34 -0700 (PDT) Received: from denic.de ([10.122.65.99]) by office.denic.de with esmtp id 1KLc8l-0002n9-Pd; Wed, 23 Jul 2008 13:04:15 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 829BE7D3477; Wed, 23 Jul 2008 13:04:15 +0200 (CEST) Date: Wed, 23 Jul 2008 13:04:15 +0200 From: Peter Koch To: IETF ENUM WG Message-ID: <20080723110415.GC52861@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <4882BCC8.9030503@e164.org> <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Tue, Jul 22, 2008 at 08:22:03PM +0100, Jim Reid wrote: > Aha! I suppose you mean delegation points and zone cuts. Well what you > say is true up to a point: though our DNSSEC friends have done a good > job of demolishing that. DS records, anyone? well, this is not only about delegations and zone cuts, but about general properties of the namespace. And even though we have a hierarchy, the DNS follows the principle that any information is published in place, not inherited from "above", because such an inheritance doesn't exist. For example, we have _lots of_ domains under DE which are maintained within the DE zone. Still no data at the DE level should apply to these domains any more or less than it applies to a delegated domain -- zero in both cases. Now, that's the general DNS rule. However, there are parts of the DNS namespace that are mappings of other name- or numberspaces, like e164.arpa. The question of hierarchy, inheritance and the like is influenced by the properties of the mapped name- or number space, not the DNS. Therefore I doubt anything "generic" at the DNS level could or should help. > Indeed. This is why I privately suggested to Ray that he replace send- > n with a new RRtype template that should sail through the 2929-bis > process. Except that it might not be eligible for the 2929bis process if it tries to be "DNS generic" and it wouldn't have the appeal of being automatically piggy backed onto the DNS response, like any NAPTR "re-use" would. > in trouble because it does not define a URI. I'm still far from > convinced about the alleged benefits of saving the odd DNS lookup: the > latency is one valid point, but some extra queries, so what? The > resolving entities will presumably acquire a rich cache very quickly, Mobile devices have been mentioned as where latency matters, but then I wonder why overlap dialling would appear with those devices in the first place, since we're usually used to press the "green" button on handhelds anyway. The figures I've seen so far re: query volume have neither been frightening nor convincing, so I'd like to re-issue my plea to first agree on the size of the problem before designing or even standardizing a solution. What I'd also like to learn during the Dublin discussion is whether "send-n" is envisioned for private I-ENUM only or also for other applications and whether the envisioned scenario (in case of private I-ENUM) would or would not involve a "normal" DNS server and resolver infrastructure, including delegations and caching, that is. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 23 04:36:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E993D3A6A22; Wed, 23 Jul 2008 04:36:51 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701FE3A6A0E for ; Wed, 23 Jul 2008 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOlKOaC6dLlD for ; Wed, 23 Jul 2008 04:36:50 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id DC1643A6A22 for ; Wed, 23 Jul 2008 04:36:49 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=EPRa30iIJB14ilvADDyxTsTyWDNEamoELUqMmhX4nie/7ujXcFDWAFtF xPMA+N+OwYWUSXacJYsqVz1F7uEkxrWsyshCNlJT2VvUGE0GCowY0aRPO FAs6kypAS36L6kU; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216813053; x=1248349053; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Enum ]=20a=20new=20RRype=20instead=20of=20send-n=20NAPTRs |Date:=20Wed,=2023=20Jul=202008=2012:37:29=20+0100 |Message-ID:=20|To:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<20080723110415.GC528 61@unknown.office.denic.de>|References:=20=0D=0A=09<4882BCC8.9030503@e164.org>=09=0D=0A=09<10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.c om>=20<20080723110415.GC52861@unknown.office.denic.de>; bh=5OyJkjxJu/70v816UO8+E1FDoWn0yzuChO2Zqh8/vBE=; b=Og3eGgil6cUhrhU4/lvz/OQGy0kgMS5azNev83c+0y6+VG9ecehxGzCN pGOhCqfOo1aovH19TEi50H8i+dfiB2ryAduC354SM4umTiqsSMXm8B+zo pX7qsNGXCzwTjhY; X-IronPort-AV: E=Sophos;i="4.31,238,1215385200"; d="scan'208";a="5362143" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Jul 2008 12:37:30 +0100 In-Reply-To: <20080723110415.GC52861@unknown.office.denic.de> References: <4882BCC8.9030503@e164.org> <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> <20080723110415.GC52861@unknown.office.denic.de> To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 23 Jul 2008 12:37:29 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/07/2008 12:37:30 PM, Serialize complete at 23/07/2008 12:37:30 PM Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Mobile devices have been mentioned as where latency matters, but then > I wonder why overlap dialling would appear with those devices in the > first place, since we're usually used to press the "green" button on > handhelds anyway. Indeed - modern "smart" devices with dial buttons are not expected to be the issue - dumb DTMF phones are. > The figures I've seen so far re: query volume have neither been frightening > nor convincing, so I'd like to re-issue my plea to first agree on the > size of the problem before designing or even standardizing a solution. I don't have any absolute volume figures available - call establishment volume data is very hard to come by. Paul Rosbotham may be able to help there. We can however model the relative saving the Send-N might achieve, although that in itself is country specific and also depends on how much base logic you're prepared to put in your switch. For +44 we know that a completely naive implementation of overlapped dialling without Send-N would do up to 12 lookups (it would be less if they got to a part of the tree that didn't exist and hence returned NXDOMAIN). A smart implementation with Send-N for +44 can do just two lookups. The first is done after the first 9 digits, and because of the properties of +44 will get either a full NAPTR or a final Send-N. If that Send-N is followed the next lookup will be a full NAPTR or NXDOMAIN. This is because the +44 number length table does not change beyond the 9th digit. There's probably a middle ground in benefit somewhere between the two, because nobody would use the completely naive method. > What I'd also like to learn during the Dublin discussion is whether "send-n" > is envisioned for private I-ENUM only or also for other applications and > whether the envisioned scenario (in case of private I-ENUM) would or > would not involve a "normal" DNS server and resolver infrastructure,including > delegations and caching, that is. It has its origins in a private I-ENUM scenario, but should multiple private I-ENUM trees become interconnected it would have uses too. The current proposal works with completely "normal" DNS server software and infrastructure, including caching. Delegation (i.e. of blocks to carriers) would work, but isn't proposed for the UK database. I don't personally have any use-cases for public ENUM in mind, but that's not to say that there aren't any. I happened to be talking to a VoIP operator yesterday who was saying that using "Address Incomplete" in SIP to try and implement overlapped dialling was anything but satisfactory because of the massive performance load caused by each new SIP dialog. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 23 05:22:40 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EB03A68CD; Wed, 23 Jul 2008 05:22:40 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9D13A68CD for ; Wed, 23 Jul 2008 05:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z77sMq6IHtF6 for ; Wed, 23 Jul 2008 05:22:37 -0700 (PDT) Received: from mail176.messagelabs.com (mail176.messagelabs.com [85.158.138.83]) by core3.amsl.com (Postfix) with SMTP id 7204F3A6894 for ; Wed, 23 Jul 2008 05:22:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-5.tower-176.messagelabs.com!1216815785!14711068!22 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 6933 invoked from network); 23 Jul 2008 12:23:18 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-5.tower-176.messagelabs.com with SMTP; 23 Jul 2008 12:23:18 -0000 Received: from GBCWSWIEM001.ad.plc.cwintra.com ([148.185.93.203]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 13:23:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 13:23:01 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] a new RRype instead of send-n NAPTRs Thread-Index: AcjsuIOhCArkkGW3RTuux3hUeZQmIQABAcwA From: "Rosbotham, Paul" To: , X-OriginalArrivalTime: 23 Jul 2008 12:23:09.0203 (UTC) FILETIME=[DDF82E30:01C8ECBE] Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Did someone mention my name? > > The figures I've seen so far re: query volume have neither been > frightening > > nor convincing, so I'd like to re-issue my plea to first > agree on the > > size of the problem before designing or even standardizing > a solution. > > I don't have any absolute volume figures available - call > establishment > volume data is very hard to come by. Paul Rosbotham may be > able to help > there. > Obviously the UK portability solution's based upon telcos taking a download of the whole thing and querying locally. So it depends on the specifics of each individual CP. Off the top of my head, a typical mid-size telco would be generating perhaps 2-3000 call attempts per second. In the "naive" / no Send-N scenario Ray mentioned...which clearly wouldn't happen because if there was no Send-N the originator would seek to construct the decode information to some extent...that would mean 25k-35k queries per second. An incumbent would generate maybe 3 or 4 times as much. There's pretty much zero correlation between the numbers called/queried at a callserver level - I guess there's scope for a degree of cacheing at a higher level...i.e. if you queried on 1.4.4.foo and got no NAPTR back, then it's worth cacheing at that level but cacheing the NAPTR returned by 6.0.5.1.5.4.2.7.7.1.e164.foo is of limited value unless you have an absolutely enormous (as in 60-70M entry) cache. Of course (separate debate on this thread) there's the issue of whether we're talking about usage of Send-N for a specific quasi-private ENUM instance, or the public e164.arpa one. I believe Ray's intent was to leverage the thinking for utilisation in the latter. The volumes of queries on public DNS is then linked to the number of users querying it. Anyone got a piece of string that I can measure? This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 23 05:31:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BACC3A68EA; Wed, 23 Jul 2008 05:31:30 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BB83A68EA for ; Wed, 23 Jul 2008 05:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMZmOqak4DId for ; Wed, 23 Jul 2008 05:31:25 -0700 (PDT) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 9A64F3A6955 for ; Wed, 23 Jul 2008 05:31:25 -0700 (PDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KLdVl-0000Cr-Ri for enum@ietf.org; Wed, 23 Jul 2008 13:32:05 +0100 Received: from [77.103.38.46] (helo=games-with-brains.net) by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52) id 1KLdVl-00067P-Bj for enum@ietf.org; Wed, 23 Jul 2008 13:32:05 +0100 Received: from [192.168.123.46] (unknown [192.168.123.254]) by games-with-brains.net (Postfix) with ESMTP id 003BC1D51B53 for ; Wed, 23 Jul 2008 13:32:03 +0100 (BST) Message-Id: From: Eleanor McHugh To: IETF ENUM WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Jul 2008 13:32:05 +0100 References: <4882BCC8.9030503@e164.org> <10B101C6-EFC4-4388-8E29-97CBBC6891FB@rfc1035.com> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 23 Jul 2008, at 09:59, Jay Daley wrote: > Jim Reid wrote on 22/07/2008 20:22:03: >> Rubbish. The DNS has never, ever cared about "ownership of labels" >> whatever that means. A client does a lookup and gets a response. It >> doesn't have the slightest interest in who "owns" the label or >> operates the name servers for it. > > I'm sure you know this, but just in case ... in DNS a parent never > makes > an authoritative statement about a child's data. If you have a new RR > Type like this that can apply to any part of DNS then it will allow a > (grand)parent to make an authoritative statement about a > (grand)child's > data. Jay, this is probably pedantry of the worst kind and I apologise in advance, but the RR Type suggested would not be making authoritative statements about the child node's data - it would be making such statements about the child node's very existence. This may or may not be a good thing from an administrative perspective as it's a slippery slope from this kind of meta-data to more generic DNS tree inspection. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net http://www.linkedin.com/in/eleanormchugh _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jul 23 05:35:40 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C19D3A696E; Wed, 23 Jul 2008 05:35:40 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE733A696E for ; Wed, 23 Jul 2008 05:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95-wetElRHOf for ; Wed, 23 Jul 2008 05:35:34 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 945EF3A6894 for ; Wed, 23 Jul 2008 05:35:34 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=krq5Lm+evOd10xIybs/u5BQovP7uPtS4nf9Dra3iWmk/uQJqPYFbfI35 xDnfSGrMTh3TF1jLW/WudiZTkUE3DvrenaYnGwHi+Yn02UYOt9iS1+8d3 x98XvgdvyYLWzH+; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216816578; x=1248352578; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[Enum ]=20a=20new=20RRype=20instead=20of=20send-n=20NAPTRs |Date:=20Wed,=2023=20Jul=202008=2013:36:15=20+0100 |Message-ID:=20|To:=20enum@ietf.org |MIME-Version:=201.0|In-Reply-To:=20 |References:=20=20; bh=fCfX+CoS+fxtnvXQY7NLXSMz1ixThQAB1kNYK38glLo=; b=bGCMenWb7XJy8tT7ZSt2ruLirFr/yHCpLkRtVUTmpqWeI8fX2VxPYBze 7giUqAShSGjqzxPyRY1E7U+5G3czwaCE1Nv3kv6j6ApabIdlD+eUaNcRc +rLUjX+bhYolHTC; X-IronPort-AV: E=Sophos;i="4.31,238,1215385200"; d="scan'208";a="4312110" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 23 Jul 2008 13:36:16 +0100 In-Reply-To: References: To: enum@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 23 Jul 2008 13:36:15 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/07/2008 01:36:16 PM, Serialize complete at 23/07/2008 01:36:16 PM Subject: Re: [Enum] a new RRype instead of send-n NAPTRs X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > Of course (separate debate on this thread) there's the issue of > whether we're talking about usage of Send-N for a specific quasi- > private ENUM instance, or the public e164.arpa one. I believe Ray's > intent was to leverage the thinking for utilisation in the latter. Not at all - I'm thinking more of international level interconnects between (private) I-ENUM trees used for different countries' NGNs. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From rkabi@birzeit.edu Fri Jul 25 08:37:26 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D2728C200 for ; Fri, 25 Jul 2008 08:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPvp3Q-6dX3k for ; Fri, 25 Jul 2008 08:37:26 -0700 (PDT) Received: from mailgw1.birzeit.edu (mailgw1.birzeit.edu [213.244.124.5]) by core3.amsl.com (Postfix) with ESMTP id E01C628C1F6 for ; Fri, 25 Jul 2008 08:37:25 -0700 (PDT) Received: from mail.birzeit.edu (mail.birzeit.edu [213.244.124.15]) by mailgw1.birzeit.edu (Postfix) with SMTP id AA0231688F8; Fri, 25 Jul 2008 18:36:02 +0300 (IDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EE6C.A6CC6D67" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Dear Webmail Subscriber Date: Fri, 25 Jul 2008 18:39:40 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dear Webmail Subscriber Thread-Index: AcjubKZXp8hzqquHRiqaE2NiAUaRvg== From: "Rasim Kabi" To: undisclosed-recipients:; X-BZU-MailScanner-Information: Please contact the ISP for more information X-BZU-MailScanner: Found to be clean X-BZU-MailScanner-From: rkabi@birzeit.edu This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EE6C.A6CC6D67 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Webmail Subscriber, How are you doing today We are the agent of the WEBMAIL SUPPORT To complete your webmail account, you must reply to this email immediately and enter your password here (*********)Failure to do this will immediately render your email address deactivated from our = database. You can also confirm your email address by logging into your webmail = account. Contcat email:account_activat01@live.com name:webmail agent Thank you for using! THE SUPPORT TEAM WEBMAIL SUPPORT. web.mail@dores.com buku.fastmail.usf.edu acomp.usf.edu ------_=_NextPart_001_01C8EE6C.A6CC6D67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Webmail Subscriber

Dear Webmail Subscriber,
How are you doing today
We are the agent of the WEBMAIL SUPPORT
To complete your webmail account, you must reply to this email
immediately and enter your password here (*********)Failure to do = this
will immediately render your email address deactivated from our = database.

You can also confirm your email address by logging into your webmail = account.
Contcat email:account_activat01@live.com
name:webmail agent

Thank you for using!
THE SUPPORT TEAM
WEBMAIL SUPPORT.
web.mail@dores.com

buku.fastmail.usf.edu
acomp.usf.edu

------_=_NextPart_001_01C8EE6C.A6CC6D67-- From enum-bounces@ietf.org Fri Jul 25 14:54:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B613A68AE; Fri, 25 Jul 2008 14:54:27 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684763A68AE; Fri, 25 Jul 2008 14:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16 X-Spam-Level: X-Spam-Status: No, score=-16 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxtoxJ4ObhXo; Fri, 25 Jul 2008 14:54:24 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 3E12A3A6859; Fri, 25 Jul 2008 14:54:20 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 1F695145AC0; Fri, 25 Jul 2008 14:54:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080725215423.1F695145AC0@bosco.isi.edu> Date: Fri, 25 Jul 2008 14:54:23 -0700 (PDT) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5278 on IANA Registration of Enumservices for Voice and Video Messaging X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5278 Title: IANA Registration of Enumservices for Voice and Video Messaging Author: J. Livingood, D. Troshynski Status: Standards Track Date: July 2008 Mailbox: jason_livingood@cable.comcast.com, dtroshynski@acmepacket.com Pages: 22 Characters: 39745 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-vmsg-02.txt URL: http://www.rfc-editor.org/rfc/rfc5278.txt This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS TRACK] This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From groy4@cogeco.ca Sat Jul 26 18:55:33 2008 Return-Path: X-Original-To: ietfarch-enum-archive@core3.amsl.com Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA8C3A67ED for ; Sat, 26 Jul 2008 18:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk6E-Cywqj24 for ; Sat, 26 Jul 2008 18:55:32 -0700 (PDT) Received: from fep1.cogeco.net (smtp.cogeco.net [216.221.81.25]) by core3.amsl.com (Postfix) with ESMTP id A6D5C3A67CE for ; Sat, 26 Jul 2008 18:55:32 -0700 (PDT) Received: from cogeco.ca (smtp2.cogeco.ca [216.221.81.29]) by fep1.cogeco.net (Postfix) with SMTP id 783BC26C4; Sat, 26 Jul 2008 21:55:34 -0400 (EDT) To: (Recipient List Suppressed) Sender: groy4@cogeco.ca From: VALDOSTA.EDU@core3.amsl.com, WEBALERTTEAM_001@core3.amsl.com, alertrectfiers400@gmail.com Reply-to: VALDOSTA.EDU@core3.amsl.com, WEBALERTTEAM_001@core3.amsl.com, alertrectfiers400@gmail.com Subject: SUBMIT YOUR ACCOUNT FOR VERIFICTION X-Mailer: Cogeco Webmail - complaints to abuse@cogeco.ca ( 193.202.63.20 - groy4 ) X-Originating-IP: 193.202.63.20 Date: Sun, 27 Jul 2008 13:55:34 +1200 X-Priority: 3 (Normal) Message-id: <488bd596.1c0.7419.18081@cogeco.ca> Dear VALDOSTA.EDU Account Owner, This message is from the VALDOSTA.EDU Webmail messaging center to SINGNET.COM.SG Webmail account owners. We are currently upgrading our data base and e-mail account center. We are deleting all unused VALDOSTA.EDU Webmail account to create more space for new accounts. To prevent your account from being closed unnecessarly, you will have to update us with the following informations below in order to know that it's a present used account. CONFIRM YOUR EMAIL IDENTITY BELOW 1.Full Email Adress...................... 2.password:............... 3.age/country:................. 4.date of birth:................ 5.First name/Last name:............. Warning Code:VX2G99AAJ Warning!!! Account owner that refuses to update his or her account within Seven days of receiving this warning will lose his or her account permanently. Than! k you for using VALDOSTA.EDU Webmail! Warning Code:VX2G99AAJ Thanks, VALDOSTA.EDU Alert team From enum-bounces@ietf.org Mon Jul 28 05:06:23 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390153A67B1; Mon, 28 Jul 2008 05:06:23 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5693A67E6 for ; Mon, 28 Jul 2008 05:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.137 X-Spam-Level: ** X-Spam-Status: No, score=2.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNlegjquUs+X for ; Mon, 28 Jul 2008 05:06:21 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 5FB243A67B1 for ; Mon, 28 Jul 2008 05:06:21 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.48644941; Mon, 28 Jul 2008 08:06:14 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 08:06:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 08:06:13 -0400 Message-ID: <45AEC6EF95942140888406588E1A66020413D9BB@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 72 - Experimental Video Conference / Chat During Meeting Thread-Index: AcjwqlHBQ5/F15OfQg+G8n25Yt+Ikw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 28 Jul 2008 12:06:14.0430 (UTC) FILETIME=[552EDBE0:01C8F0AA] Subject: [Enum] IETF 72 - Experimental Video Conference / Chat During Meeting X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Totally an experiment. Try to access this and enter as guest. http://training.comcast.net/jlivingood Jason _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jul 28 08:15:09 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A92D28C15F; Mon, 28 Jul 2008 08:15:09 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2F928C15F for ; Mon, 28 Jul 2008 08:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0bGLGqyA5GH for ; Mon, 28 Jul 2008 08:15:07 -0700 (PDT) Received: from mail.songbird.com (unknown [IPv6:2001:470:1:76:2c0:9fff:fe3e:4009]) by core3.amsl.com (Postfix) with ESMTP id 930E428C153 for ; Mon, 28 Jul 2008 08:15:06 -0700 (PDT) Received: from rshockeyPC ([130.129.55.65]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m6SFAbrj022297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jul 2008 08:11:55 -0700 From: "Richard Shockey" To: Date: Mon, 28 Jul 2008 11:11:32 -0400 Message-ID: <0e2601c8f0c4$6e3236e0$4a96a4a0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjwrMxSrQ29Kj7zTaqayltaelF9kg== Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Enum] Reminder to get us your slides for the meeting ASAP X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Send them to me or Alex and we'll take care of them. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jul 29 10:55:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D76A3A69EC; Tue, 29 Jul 2008 10:55:33 -0700 (PDT) X-Original-To: enum@core3.amsl.com Delivered-To: enum@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16743A6910 for ; Tue, 29 Jul 2008 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb83Rh3A4xMY for ; Tue, 29 Jul 2008 10:55:31 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id C76973A68B2 for ; Tue, 29 Jul 2008 10:55:30 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.9530930; Tue, 29 Jul 2008 13:55:10 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 13:55:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:54:37 -0400 Message-ID: <45AEC6EF95942140888406588E1A66020413D9F4@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 72 - Experimental Video Conference / Chat During Meeting Thread-Index: AcjwqlHBQ5/F15OfQg+G8n25Yt+IkwA+dkjP References: <45AEC6EF95942140888406588E1A66020413D9BB@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 29 Jul 2008 17:55:11.0304 (UTC) FILETIME=[3EF20C80:01C8F1A4] Subject: Re: [Enum] IETF 72 - Experimental Video Conference / Chat During Meeting X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Video + audio broadcasting now... ________________________________ From: enum-bounces@ietf.org on behalf of Livingood, Jason Sent: Mon 7/28/2008 8:06 AM To: enum@ietf.org Subject: [Enum] IETF 72 - Experimental Video Conference / Chat During Meeting Totally an experiment. Try to access this and enter as guest. http://training.comcast.net/jlivingood Jason _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum