From enum-bounces@ietf.org Wed Apr 2 01:40:13 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6EB3A6B15; Wed, 2 Apr 2008 01:40: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 0FAC33A6B15 for ; Wed, 2 Apr 2008 01:40:12 -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 k2BjtnflQ+De for ; Wed, 2 Apr 2008 01:40:11 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 10B133A6AA9 for ; Wed, 2 Apr 2008 01:40:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,592,1199664000"; d="scan'208";a="17375" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 02 Apr 2008 09:40:10 +0100 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: Wed, 2 Apr 2008 09:40:08 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/04/2008 09:40:09 AM, Serialize complete at 02/04/2008 09:40:09 AM Subject: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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've just submitted a new I-D, available at Filename: draft-bellis-enum-send-n Revision: 00 Title: IANA Registrations for the 'Send-N' Enumservice Creation_date: 2008-04-02 WG ID: Independent Submission Number_of_pages: 10 Abstract: 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) enabled applications. Any and all (constructive) feedback gratefully received! regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From jrhall@andrew.cmu.edu Wed Apr 2 02:26:31 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 3FD5B28C3E9 for ; Wed, 2 Apr 2008 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_71=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, US_DOLLARS_3=0.63] 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 OSErD2JjHi8v for ; Wed, 2 Apr 2008 02:26:30 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.212]) by core3.amsl.com (Postfix) with ESMTP id 65AFF28C2F8 for ; Wed, 2 Apr 2008 02:26:30 -0700 (PDT) Received: from webmail.andrew.cmu.edu (WEBMAIL9.andrew.cmu.edu [128.2.10.108]) (user=jrhall mech=GSSAPI (56 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id m329OvYq023370; Wed, 2 Apr 2008 05:25:52 -0400 Received: from 41.219.216.40 (SquirrelMail authenticated user jrhall@ANDREW.CMU.EDU); by webmail.andrew.cmu.edu with HTTP; Wed, 2 Apr 2008 05:25:54 -0400 (EDT) Message-ID: <4157.41.219.216.40.1207128354.squirrel@41.219.216.40> Date: Wed, 2 Apr 2008 05:25:54 -0400 (EDT) Subject: HELLO. From: "khalid mahmoud." Reply-To: khalidmahmouds@yahoo.com.hk User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212 To: undisclosed-recipients:; I am khalid mahmoud from Bahrain,I have been diagnosed with Oesophageal cancer. It has defied all forms of medical treatment,I have few months to live. I have decided to give alms to charity organizations. I cannot do this myself because of my health. I have Eighteen Million dollars ($18,000,000,00) with a finance House abroad. Can you help me collect this deposit and dispatch it to charity organizations? You will take 20% for your assistance. I WOULD WANT YOU TO REACH ME VIA MY PRIVATE EMAIL IF YOU ARE WILLING TO ASSIST ME. ( khalidmahmouds@yahoo.com.hk ) From enum-bounces@ietf.org Wed Apr 2 13:10:44 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ABD28C145; Wed, 2 Apr 2008 13:10: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 E390F28C20D for ; Wed, 2 Apr 2008 13:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 C1FI2c8zvl-P for ; Wed, 2 Apr 2008 13:10:34 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 988D63A67F2 for ; Wed, 2 Apr 2008 13:10:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1207167031!23047925!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22543 invoked from network); 2 Apr 2008 20:10:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2008 20:10:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m32KAV9i010566 for ; Wed, 2 Apr 2008 16:10:31 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m32KAFES010388 for ; Wed, 2 Apr 2008 16:10:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:10:12 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Thread-Index: AciUnTWfcoYYf8XtRcm5EU9NAhw6FgAXmw5w References: From: "PFAUTZ, PENN L, ATTCORP" To: , Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: I'm having a little trouble understanding the real need for this enumservice. I would think that any network element receiving a dial string would have its own local information about dial patterns and numbers and so be able to tell when dialing is complete and then be able to formulate an ENUM query on the appropriate full E.164 number. Since the number length information should be relatively static, why not just provision it locally? Also, it's not clear to me when the client would initiate the initial query in the example that told it to expect 5-6 more digits. And, if it's 5-6, then if the number has only 5, don't I still have to use a timeout algorithm to determine the user is finished dialing. Am I missing something? Penn Pfautz -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Ray.Bellis@nominet.org.uk Sent: Wednesday, April 02, 2008 4:40 AM To: enum@ietf.org Subject: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 I've just submitted a new I-D, available at Filename: draft-bellis-enum-send-n Revision: 00 Title: IANA Registrations for the 'Send-N' Enumservice Creation_date: 2008-04-02 WG ID: Independent Submission Number_of_pages: 10 Abstract: 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) enabled applications. Any and all (constructive) feedback gratefully received! regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ 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 Wed Apr 2 14:04:00 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE173A6F56; Wed, 2 Apr 2008 14:04: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 72EA53A6F58 for ; Wed, 2 Apr 2008 14:03:59 -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 tUqYiSf8jhg9 for ; Wed, 2 Apr 2008 14:03:58 -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 312623A6F48 for ; Wed, 2 Apr 2008 14:03:57 -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 m32L3t99004649Wed, 2 Apr 2008 21:03:55 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhA7f-000Icz-00; Wed, 02 Apr 2008 22:03:55 +0100 Date: Wed, 2 Apr 2008 22:03:55 +0100 From: "Clive D.W. Feather" To: "PFAUTZ, PENN L, ATTCORP" Message-ID: <20080402210355.GA71089@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.5.3i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 PFAUTZ, PENN L, ATTCORP said: > I'm having a little trouble understanding the real need for this > enumservice. I would think that any network element receiving a dial > string would have its own local information about dial patterns and > numbers and so be able to tell when dialing is complete and then be able > to formulate an ENUM query on the appropriate full E.164 number. > Since the number length information should be relatively static, why not > just provision it locally? While the information should be static, it's also very complicated and it might not be practical for the network element to store it all. In the UK we have number ranges where the length varies in a very localised way; it might be that: 0456 789 0xx numbers are all 10 digits 0456 789 1xxx numbers are all 11 digits (these are hypothetical examples because I can't get to the relevant database right now). Germany has situations where the customer determines the length of numbers. > Also, it's not clear to me when the client would initiate the initial > query in the example that told it to expect 5-6 more digits. The client would know, perhaps, that *every* number beginning 0 has at least 7 digits. So it would initiate the query after receiving those 7. > And, if > it's 5-6, then if the number has only 5, don't I still have to use a > timeout algorithm to determine the user is finished dialing. > Am I missing something? In the UK there are no numbers that are prefixes of other numbers. That is, when you've received enough digits, you'll know you've reached the end. But you may need several digits to do so - see the above examples. -- 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 calendar-invite@reply.yahoo.com Wed Apr 2 15:32:58 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 530B93A6D74 for ; Wed, 2 Apr 2008 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.631 X-Spam-Level: *** X-Spam-Status: No, score=3.631 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_65=0.6, SARE_SUB_NEED_REPLY=0.784, 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 e+hUSZ3cKe-t for ; Wed, 2 Apr 2008 15:32:57 -0700 (PDT) Received: from n15.bullet.sp1.yahoo.com (n15.bullet.sp1.yahoo.com [69.147.64.212]) by core3.amsl.com (Postfix) with SMTP id 870C73A6B9A for ; Wed, 2 Apr 2008 15:32:57 -0700 (PDT) Received: from [216.252.122.217] by n15.bullet.sp1.yahoo.com with NNFMP; 02 Apr 2008 22:32:58 -0000 Received: from [66.218.69.2] by t2.bullet.sp1.yahoo.com with NNFMP; 02 Apr 2008 22:32:58 -0000 Received: from [68.142.194.244] by t2.bullet.scd.yahoo.com with NNFMP; 02 Apr 2008 22:32:58 -0000 Received: from [209.191.93.245] by t2.bullet.mud.yahoo.com with NNFMP; 02 Apr 2008 22:32:58 -0000 Date: 02 Apr 2008 15:32:58 -0700 Received: from [127.0.0.1] by web122.cal.pim.mud.yahoo.com with NNFMP; 02 Apr 2008 22:32:58 -0000 x-yahoo-newman-errors: calendar-invite.onqxkx3cmvwgy3zug43sg2rtfuytembxge3tknjxhawxgylvl5rgk3dmn42donzdniztumjxge-enum-archive=ietf.org@returns.bulk.yahoo.com MIME-Version: 1.0 Reply-to: sau_bello477@yahoo.com Errors-To: sau_bello477@yahoo.com From: Sau Bello To: enum-archive@ietf.org Subject: I AM URGENTLY WAITING FOR YOUR REPLY X-Yahoo-Newman-Property: calendar-invite X-Yahoo-Newman-Id: sau_bello477#j3-1207175578-sau_bello477#j3:171 X-Yahoo-Calendar-Iid: gxafMqjC0Op3aEs4VxCOpTd%40NgND%40F3fuhA4Ax%40%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=AGJpyye2IVFKqEzqZaEMrU9t3hKlZPK1207175554-1" Message-Id: <20080402223257.870C73A6B9A@core3.amsl.com> --YCalInvites=AGJpyye2IVFKqEzqZaEMrU9t3hKlZPK1207175554-1 Content-type: text/plain; charset=windows-1252; You are invited to "I AM URGENTLY WAITING FOR YOUR REPLY". By your host Sau Bello: From the desk of Dr.sau bello, Bill and exchange manager, Bank of africa, Ouagadougou Annex, Dear Friend,First and foremost,accept my apologies and write me back to this email : l am the manager of bills and exchange section at the foreign remtttance department of bank of africa here in Ouagadougou,Burkina faso,in my department we discovered an$22.2m usd please mail me for details. Date: Wednesday April 2, 2008 Time: 10:00 pm - 11:00 pm (GMT +00:00) Location: I AM URGENTLY WAITING FOR YOUR REPLY Will you attend? RSVP to this invitation at: http://calendar.yahoo.com/sau_bello477?v=126&a1=0&iid=gxafMqjC0Op3aEs4VxCOpTd%40NgND%40F3fuhA4Ax%40%40&igid=whadpejAKNQ5%40C0P6xb0UUd%40FpaSaHheahAm647c2ov%40 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=AGJpyye2IVFKqEzqZaEMrU9t3hKlZPK1207175554-1 Content-type: text/html; charset=windows-1252;
You're invited to:   I AM URGENTLY WAITING FOR YOUR REPLY
By your host:   Sau Bello
 
Message:   From the desk of Dr.sau bello,
Bill and exchange manager,
Bank of africa, Ouagadougou Annex,
Dear Friend,First and foremost,accept my apologies and write me back to this email :
l am the manager of bills and exchange section at the foreign remtttance department of bank of africa here in Ouagadougou,Burkina faso,in my department we discovered an$22.2m usd please mail me for details.


 
Date:   Wednesday April 2, 2008
Time:   10:00 pm - 11:00 pm  (GMT +00:00)
Location:   I AM URGENTLY WAITING FOR YOUR REPLY
 
Will you attend?   RSVP to this invitation
Copyright © 2008  Yahoo! Inc. All Rights Reserved | Terms of Service | Privacy Policy
--YCalInvites=AGJpyye2IVFKqEzqZaEMrU9t3hKlZPK1207175554-1-- From enum-bounces@ietf.org Wed Apr 2 15:42:11 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9713A693A; Wed, 2 Apr 2008 15:42:11 -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 DB1463A693A for ; Wed, 2 Apr 2008 15:42:09 -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 tpq5R5CoQ7np for ; Wed, 2 Apr 2008 15:42:09 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 2928C3A689E for ; Wed, 2 Apr 2008 15:42:09 -0700 (PDT) Received: from [192.168.100.101] (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 9F3565AC364 for ; Thu, 3 Apr 2008 09:42:12 +1100 (EST) Message-ID: <47F40BBF.1050308@e164.org> Date: Thu, 03 Apr 2008 08:42:07 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org >> \"enum@ietf.org\"" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> In-Reply-To: <20080402210355.GA71089@finch-staff-1.thus.net> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > While the information should be static, it's also very complicated and it > might not be practical for the network element to store it all. In the UK > we have number ranges where the length varies in a very localised way; it > might be that: A similar thing occurs in Australia and I recently parsed the CSV file published by the ACMA of all prefixes it is authorised to allocate or has been allocated and its a horrible mess of sorts. So I can see how this might be useful especially for keeping up with changes globally to the benefit of all but without everyone needing to keep local databases or updating their own databases themselves. > The client would know, perhaps, that *every* number beginning 0 has at > least 7 digits. So it would initiate the query after receiving those 7. I'm not exactly clear on when DNS queries should be triggered, or how many need to be requested either or if these would interfere with existing wild card entries. I don't have time this morning to test but I like the idea a lot and I very much would like to see it or some variation of it work. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 2 16:01:06 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022C428C56E; Wed, 2 Apr 2008 16:01: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 902AB28C54C for ; Wed, 2 Apr 2008 16:01:04 -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 DlaBYAGG+0GX for ; Wed, 2 Apr 2008 16:01:03 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id E57BA28C5AE for ; Wed, 2 Apr 2008 16:00:52 -0700 (PDT) Received: from [192.168.100.101] (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 85CD05AC364 for ; Thu, 3 Apr 2008 10:00:56 +1100 (EST) Message-ID: <47F41023.3080902@e164.org> Date: Thu, 03 Apr 2008 09:00:51 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <47F40BBF.1050308@e164.org> In-Reply-To: <47F40BBF.1050308@e164.org> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Clive D.W. Feather wrote: > >> While the information should be static, it's also very complicated and it >> might not be practical for the network element to store it all. In the UK >> we have number ranges where the length varies in a very localised way; it >> might be that: > > A similar thing occurs in Australia and I recently parsed the CSV file > published by the ACMA of all prefixes it is authorised to allocate or > has been allocated and its a horrible mess of sorts. So I can see how > this might be useful especially for keeping up with changes globally to > the benefit of all but without everyone needing to keep local databases > or updating their own databases themselves. I meant to provide a link to the results of where I parsed the Australian information in the first place, sorry. http://www.e164.org/wiki/AU_Dialplan The information at the top is a simplified version which most people would be able to live with, however the full listing which appears at the bottom is the most accurate description of the Australian numbering plan as of about 3 weeks ago. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 2 16:11:01 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28843A6B59; Wed, 2 Apr 2008 16:11: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 E3D673A6944 for ; Wed, 2 Apr 2008 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.288 X-Spam-Level: X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=2.311, 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 ZH8QQpSMpzNw for ; Wed, 2 Apr 2008 16:10:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F91E28C1EB for ; Wed, 2 Apr 2008 16:10:20 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 16:10:22 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m32NAMnA009741; Wed, 2 Apr 2008 16:10:22 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m32NALtN007951; Wed, 2 Apr 2008 23:10:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 19:10:21 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 19:10:21 -0400 Message-ID: <47F41276.30404@cisco.com> Date: Wed, 02 Apr 2008 19:10:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Duane References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <47F40BBF.1050308@e164.org> In-Reply-To: <47F40BBF.1050308@e164.org> X-OriginalArrivalTime: 02 Apr 2008 23:10:21.0478 (UTC) FILETIME=[B98B1C60:01C89516] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1922; t=1207177822; x=1208041822; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20; bh=4dJc9v4Gx8Q/jydE2soHfOVPQolYfTizq8KdtF27ZO4=; b=BpCCG7DcIqqwakmjr3yCTyqXpJUPij6khcrZ/VlYVFBz3z7oBc2PcJeaqC uw7nCRdIKuxUrWhCH+d8xt0xOWEUNaruaHr0My3Cq5HZ+XJqgoAAaJE9oAVq k+zGoRZEaW; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "enum@ietf.org >> \"enum@ietf.org\"" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 This would be good *if* we could be assured that there would be enough public ENUM entries to define the endpoint of all dial strings. I guess each device must at least know how to get to the country level. After that, there ought to at least be one of these entries for the country code. For each country there ought to be either a fixed length or a range. If a range, then there ought to be an entry for each string of length equal to the minimum of the range, which narrows it down. Then the USA could continue to dawdle on enum support, since there can be a fixed length for all of the NANP. Those countries with variable length numbers would have a harder requirement for enum support. Paul Duane wrote: > Clive D.W. Feather wrote: > >> While the information should be static, it's also very complicated and it >> might not be practical for the network element to store it all. In the UK >> we have number ranges where the length varies in a very localised way; it >> might be that: > > A similar thing occurs in Australia and I recently parsed the CSV file > published by the ACMA of all prefixes it is authorised to allocate or > has been allocated and its a horrible mess of sorts. So I can see how > this might be useful especially for keeping up with changes globally to > the benefit of all but without everyone needing to keep local databases > or updating their own databases themselves. > >> The client would know, perhaps, that *every* number beginning 0 has at >> least 7 digits. So it would initiate the query after receiving those 7. > > I'm not exactly clear on when DNS queries should be triggered, or how > many need to be requested either or if these would interfere with > existing wild card entries. > > I don't have time this morning to test but I like the idea a lot and I > very much would like to see it or some variation of it work. > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 2 16:32:03 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21BD3A6831; Wed, 2 Apr 2008 16:32:03 -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 8D47628C376 for ; Wed, 2 Apr 2008 16:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=2.203, 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 ZwINT05xQXke for ; Wed, 2 Apr 2008 16:31:55 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 8033828C1D9 for ; Wed, 2 Apr 2008 16:30:51 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 7267389A1E; Thu, 3 Apr 2008 00:30:52 +0100 (BST) Message-Id: From: Lawrence Conroy To: Clive D.W.Feather In-Reply-To: <20080402210355.GA71089@finch-staff-1.thus.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 00:30:52 +0100 References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> X-Mailer: Apple Mail (2.919.2) Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, "PFAUTZ, PENN L, ATTCORP" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Clive, Penn, Ray, folks, I am somewhat discomforted by this thread. IMHO it's a damn good idea having (in effect) an digit length analysis tree in DNS. It sure as heck beats looking through the different CSV/Excel/Access/... formats in which different Regulators publish their number plans. However, the ENUM standard doesn't seem to be set up to allow definition of these useful records. This may not be appropriate for E2U, but instead be another DDDS application entirely. Otmar, Alex, and Michael have had similar ideas, and they didn't prevail even though they were neat proposals. Heck, Rchard Stastny and I had some fun with VOID, and were reminded that THAT won't fly in ENUM with block numbers. Scott has released a draft of rfc3761bis-03. NOTE WELL - this has NOT changed the applicability text of 3761 at all. Dialing Plans are specifically excluded from ENUM. Thus before the esteemed SIP aficionados dive in, ENUM is about numbers, not dialed digit strings. An ENUM client is also expected to make an ENUM query only where it believes it has a complete E.164 number. RFC 3761 goes on to accept that a client may not know what constitutes a valid E.164 number (some of us call outside the NANP :). In principle only having a partial view of global number plans is not good enough. The idea of provisioning every nation state's number plan locally into every switch is surely not what was meant. ** However, it is pushing this a bit far to send out an ENUM query with a partially collected number, in the expectation of getting back an ISUP SND style response. This is not something the originating node believes is a complete number - it's something it suspects isn't. Thus whilst I really like the concept, I fear that ENUM is not the appropriate carrier. all the best, Lawrence --------- ** We have had this number plan discussion many times before. In the NANP, numbering is (usually) easy. Dialing is another matter, but that's way out of scope. In the UK one can at least know what constitutes a valid number length, BUT this is not immediate - one needs to have some digits to do the analysis. Thus whilst a (semi) static analysis tree is possible (see ), as Clive states, the length of numbers in the UK is prefix dependent. Also as Clive points out, there are no subsets - again, look at the numbering plan files. In Germany and Austria, all bets on number length are off, as these nation states have open numbering plans. However, again, they don't have independent numbers as subsets of others. This should come as no surprise at all to someone in the business. I am thus once again puzzled by this resurgence. Is this another game of WhackaMole? ---------- On 2 Apr 2008, at 22:03, Clive D.W. Feather wrote: > PFAUTZ, PENN L, ATTCORP said: >> I'm having a little trouble understanding the real need for this >> enumservice. I would think that any network element receiving a dial >> string would have its own local information about dial patterns and >> numbers and so be able to tell when dialing is complete and then be >> able >> to formulate an ENUM query on the appropriate full E.164 number. >> Since the number length information should be relatively static, >> why not >> just provision it locally? > > While the information should be static, it's also very complicated > and it > might not be practical for the network element to store it all. In > the UK > we have number ranges where the length varies in a very localised > way; it > might be that: > 0456 789 0xx numbers are all 10 digits > 0456 789 1xxx numbers are all 11 digits > (these are hypothetical examples because I can't get to the relevant > database right now). > > Germany has situations where the customer determines the length of > numbers. > >> Also, it's not clear to me when the client would initiate the initial >> query in the example that told it to expect 5-6 more digits. > > The client would know, perhaps, that *every* number beginning 0 has at > least 7 digits. So it would initiate the query after receiving those > 7. > >> And, if >> it's 5-6, then if the number has only 5, don't I still have to use a >> timeout algorithm to determine the user is finished dialing. >> Am I missing something? > > In the UK there are no numbers that are prefixes of other numbers. > That is, > when you've received enough digits, you'll know you've reached the > end. But > you may need several digits to do so - see the above examples. > > -- > 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 Wed Apr 2 18:48:02 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F28628C40B; Wed, 2 Apr 2008 18:48: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 75C0628C50F for ; Wed, 2 Apr 2008 18:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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-LP69zNzDdB for ; Wed, 2 Apr 2008 18:48:00 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 2F12928C40B for ; Wed, 2 Apr 2008 18:48:00 -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 m331kuiD005271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2008 17:46:59 -0800 From: "Richard Shockey" To: "'Lawrence Conroy'" , "'Clive D.W.Feather'" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> In-Reply-To: Date: Wed, 2 Apr 2008 21:47:38 -0400 Message-ID: <029101c8952c$b4eed5f0$1ecc81d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciVGbheazPOyFhyTXebR+sGKSYdDwAERhCw 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, "'PFAUTZ, PENN L, ATTCORP'" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Chair hat off .. Lawrence I generally agree with the thrust of your analysis. I find it very difficult to support the use of 3761 for digit analysis. 3761 was designed to query on the full E.164 string not a partial string. We would be going down a rat hole we do not want to go, especially now. ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The digit strings must be fully formed in advance before query not during. We have seen the German arguments etc and have passed on those etc. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Lawrence Conroy > Sent: Wednesday, April 02, 2008 7:31 PM > To: Clive D.W.Feather > Cc: Ray.Bellis@nominet.org.uk; enum@ietf.org; PFAUTZ, PENN L, ATTCORP > Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n- > 00 > > Hi Clive, Penn, Ray, folks, > > I am somewhat discomforted by this thread. IMHO it's a damn good idea > having (in effect) an digit length analysis tree in DNS. It sure as > heck beats looking through the different CSV/Excel/Access/... formats > in which different Regulators publish their number plans. > > However, the ENUM standard doesn't seem to be set up to allow > definition of these useful records. This may not be appropriate for > E2U, but instead be another DDDS application entirely. Otmar, Alex, > and Michael have had similar ideas, and they didn't prevail even > though they were neat proposals. Heck, Rchard Stastny and I had some > fun with VOID, and were reminded that THAT won't fly in ENUM with > block numbers. > > > Scott has released a draft of rfc3761bis-03. > NOTE WELL - this has NOT changed the applicability text of 3761 at > all. > Dialing Plans are specifically excluded from ENUM. Thus before the > esteemed SIP aficionados dive in, ENUM is about numbers, not dialed > digit strings. > > An ENUM client is also expected to make an ENUM query only where it > believes it has a complete E.164 number. RFC 3761 goes on to accept > that a client may not know what constitutes a valid E.164 number (some > of us call outside the NANP :). > > In principle only having a partial view of global number plans is not > good enough. The idea of provisioning every nation state's number plan > locally into every switch is surely not what was meant. ** > > However, it is pushing this a bit far to send out an ENUM query with a > partially collected number, in the expectation of getting back an ISUP > SND style response. This is not something the originating node > believes is a complete number - it's something it suspects isn't. Thus > whilst I really like the concept, I fear that ENUM is not the > appropriate carrier. > > all the best, > Lawrence > --------- > ** > We have had this number plan discussion many times before. In the > NANP, numbering is (usually) easy. Dialing is another matter, but > that's way out of scope. > In the UK one can at least know what constitutes a valid number > length, BUT this is not immediate - one needs to have some digits to > do the analysis. > Thus whilst a (semi) static analysis tree is possible (see > >), as Clive states, the length of numbers in the UK is prefix > dependent. Also as Clive points out, there are no subsets - again, > look at the numbering plan files. > In Germany and Austria, all bets on number length are off, as these > nation states have open numbering plans. However, again, they don't > have independent numbers as subsets of others. > This should come as no surprise at all to someone in the business. > I am thus once again puzzled by this resurgence. Is this another game > of WhackaMole? > ---------- > > On 2 Apr 2008, at 22:03, Clive D.W. Feather wrote: > > PFAUTZ, PENN L, ATTCORP said: > >> I'm having a little trouble understanding the real need for this > >> enumservice. I would think that any network element receiving a > dial > >> string would have its own local information about dial patterns and > >> numbers and so be able to tell when dialing is complete and then be > >> able > >> to formulate an ENUM query on the appropriate full E.164 number. > >> Since the number length information should be relatively static, > >> why not > >> just provision it locally? > > > > While the information should be static, it's also very complicated > > and it > > might not be practical for the network element to store it all. In > > the UK > > we have number ranges where the length varies in a very localised > > way; it > > might be that: > > 0456 789 0xx numbers are all 10 digits > > 0456 789 1xxx numbers are all 11 digits > > (these are hypothetical examples because I can't get to the relevant > > database right now). > > > > Germany has situations where the customer determines the length of > > numbers. > > > >> Also, it's not clear to me when the client would initiate the > initial > >> query in the example that told it to expect 5-6 more digits. > > > > The client would know, perhaps, that *every* number beginning 0 has > at > > least 7 digits. So it would initiate the query after receiving those > > 7. > > > >> And, if > >> it's 5-6, then if the number has only 5, don't I still have to use > a > >> timeout algorithm to determine the user is finished dialing. > >> Am I missing something? > > > > In the UK there are no numbers that are prefixes of other numbers. > > That is, > > when you've received enough digits, you'll know you've reached the > > end. But > > you may need several digits to do so - see the above examples. > > > > -- > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 2 23:41:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F6A3A692E; Wed, 2 Apr 2008 23:41: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 207323A692E for ; Wed, 2 Apr 2008 23:41:47 -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 yibjOvMViOCR for ; Wed, 2 Apr 2008 23:41: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 8F38E3A6AA1 for ; Wed, 2 Apr 2008 23:41:44 -0700 (PDT) Received: from [192.168.100.101] (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 1F9065AC365 for ; Thu, 3 Apr 2008 17:41:49 +1100 (EST) Message-ID: <47F47C27.2060702@e164.org> Date: Thu, 03 Apr 2008 16:41:43 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > NOTE WELL - this has NOT changed the applicability text of 3761 at all. > Dialing Plans are specifically excluded from ENUM. Thus before the > esteemed SIP aficionados dive in, ENUM is about numbers, not dialed > digit strings. This is a little more grey then you seem to be painting, even if no dns checks are made until the full length is hit I see this as useful even for non-SIP/non-VoIP applications since in theory sending an email to a phone number and having the email application doing an enum lookup could do a check to see if the number exists and failing that could also check that the length is valid. > An ENUM client is also expected to make an ENUM query only where it > believes it has a complete E.164 number. RFC 3761 goes on to accept > that a client may not know what constitutes a valid E.164 number (some > of us call outside the NANP :). Some of us rarely call inside the NANP :) > However, it is pushing this a bit far to send out an ENUM query with a > partially collected number, in the expectation of getting back an ISUP > SND style response. This is not something the originating node > believes is a complete number - it's something it suspects isn't. Thus > whilst I really like the concept, I fear that ENUM is not the > appropriate carrier. As above only send out queries as necessary to verify the length is valid and I can see how this would be useful to all aspects of ENUM queries. I also agree that specifically in terms of SIP/VoIP it would be a bad idea and would create a lot of noise to send out numerous queries before the any inter-digit timeouts occur. Although if one thinks about it national dial plans rarely change, and the only exception here being the open numbering plan in Germany and Austria, so fixed numbering plans could in theory have relatively long time to live values to over come problems with noise/excessive queries. I will have time shortly to play further with this to see how it would effect other DNS entries and will comment more on the technical problems after that. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 00:07:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0D13A68E1; Thu, 3 Apr 2008 00:07: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 A25DC3A6F4B for ; Thu, 3 Apr 2008 00:07:08 -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 Q8VO3LGKEu+v for ; Thu, 3 Apr 2008 00:06: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 DAC4F28C4C8 for ; Thu, 3 Apr 2008 00:05:38 -0700 (PDT) Received: from [192.168.100.101] (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 C75F15AC364 for ; Thu, 3 Apr 2008 18:05:44 +1100 (EST) Message-ID: <47F481C1.60805@e164.org> Date: Thu, 03 Apr 2008 17:05:37 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> In-Reply-To: <029101c8952c$b4eed5f0$1ecc81d0$@us> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Chair hat off .. > > Lawrence I generally agree with the thrust of your analysis. I find it very > difficult to support the use of 3761 for digit analysis. 3761 was designed > to query on the full E.164 string not a partial string. We would be going > down a rat hole we do not want to go, especially now. > > ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The > digit strings must be fully formed in advance before query not during. We > have seen the German arguments etc and have passed on those etc. If not ENUM, then where does this best fit? I have doubts about the technical suitability because I can see where and how it would interfere with existing records, sorry got distracted and haven't actually done testing. That said I can see benefit for all ENUM services in being able to find out if the number is actually valid and using e164.arpa while ambition was a neat idea to distribute the work back on the regulatory bodies which is why this was being pushed via ENUM rather then a new service, and this would also hit exceptions that include Germany etc as well. Even if a new DNS or other service was invented to cover this, is there any corrot that can be offered to get people to add and keep this information updated without the stick from some regulatory body, although this only applies for a small subset of countries, most countries will have fixed numbering plans, even the NANP has variable length numbering based on the prefixes (911, 411, etc), although they would be special services redirected to normal numbers in the same area I guess so hmmm. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 00:26:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A2228C278; Thu, 3 Apr 2008 00:26: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 070DC28C1DD for ; Thu, 3 Apr 2008 00:26:48 -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 rHUw+K09ymdK for ; Thu, 3 Apr 2008 00:26:45 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 8A7EE3A6898 for ; Thu, 3 Apr 2008 00:26:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,597,1199664000"; d="scan'208";a="52328" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Apr 2008 08:26:46 +0100 In-Reply-To: <029101c8952c$b4eed5f0$1ecc81d0$@us> 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: Thu, 3 Apr 2008 08:26:45 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/04/2008 08:26:45 AM, Serialize complete at 03/04/2008 08:26:45 AM Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > Chair hat off .. > > Lawrence I generally agree with the thrust of your analysis. I find it very > difficult to support the use of 3761 for digit analysis. 3761 was designed > to query on the full E.164 string not a partial string. We would be going > down a rat hole we do not want to go, especially now. > > ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The > digit strings must be fully formed in advance before query not during. We > have seen the German arguments etc and have passed on those etc. Like it or not, for now at least it seems that private ENUM has been somewhat more successful than public ENUM. The specific application for which this was originally designed is the UK's number portability database, where a private ENUM tree is used and where it is not known in advance to the application whether a complete number has been received. The intent is to avoid excessive dips into that database, not least because there may be a (financial) cost associated with each dip. If one does need this data (which NICC believe we do) then it makes absolute sense for it to be included in the ENUM tree. By doing so we allow the central portability database to maintain a single protocol interface with the Communications Providers that are querying it. When the CP asks for a NAPTR, they either get routing data, or a hint that more digits are required *from the same DNS request*. cheers, Ray p.s. if it would make people happier I can quite readily change the examples so that they're not in e164.arpa. -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 01:06:32 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7310228C3A2; Thu, 3 Apr 2008 01:06: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 7F2CF3A6AD0 for ; Thu, 3 Apr 2008 01:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 pR5fV8yT9+r0 for ; Thu, 3 Apr 2008 01:06:29 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 6F0093A6B8C for ; Thu, 3 Apr 2008 01:06:29 -0700 (PDT) Received: from [10.10.0.105] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 60E624C6B8; Thu, 3 Apr 2008 10:06:29 +0200 (CEST) Message-ID: <47F4900D.4080609@nic.at> Date: Thu, 03 Apr 2008 10:06:37 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: In-Reply-To: Cc: enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > > Any and all (constructive) feedback gratefully received! > Your definition of the min and max fields are relative to the location of the NAPTR record: The 'digitsmin' field of the data MUST correspond to the minimum number of additional digits to be dialled, relative to the current record, which might result in reaching a full ENUM record in the ENUM database. Wouldn't it be easier to use absolute values here? /ol _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 01:18:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A708328C3CC; Thu, 3 Apr 2008 01:18: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 64FF43A6927 for ; Thu, 3 Apr 2008 01:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FRT_PROFILE2=1.981] 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 ypuP6Y4GkB0W for ; Thu, 3 Apr 2008 01:18:46 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 0258928C3CC for ; Thu, 3 Apr 2008 01:18:45 -0700 (PDT) Received: from [192.168.100.101] (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 6487F5AC364 for ; Thu, 3 Apr 2008 19:18:51 +1100 (EST) Message-ID: <47F492E3.1020906@e164.org> Date: Thu, 03 Apr 2008 18:18:43 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Like it or not, for now at least it seems that private ENUM has been > somewhat more successful than public ENUM. I haven't seen dns request stats on e164.arpa, but last time they were announced e164.org was getting more. In any case I see this useful for a lot of VoIP and non-VoIP applications even if the primary beneficiary at this stage would be VSPs and proficient home users at this stage. > If one does need this data (which NICC believe we do) then it makes > absolute sense for it to be included in the ENUM tree. By doing so we > allow the central portability database to maintain a single protocol > interface with the Communications Providers that are querying it. When > the CP asks for a NAPTR, they either get routing data, or a hint that more > digits are required *from the same DNS request*. I don't think it is technically feasible, sorry still haven't done testing but I can see where it would fail immediately without testing as written in the RFC. To get routing data and prefix lengths or hints at the same time without breaking other things such as wild card records as the most specific entry would block the wild card. > p.s. if it would make people happier I can quite readily change the > examples so that they're not in e164.arpa. It wouldn't matter I don't think, due to the technical issue alone above I think there is no way to avoid multiple packets of some description so you might be better off almost writing a new service rather then trying to bolt it onto DNS for no benefit. For example a simple service daemon listing on a UDP port could take requests for a number and return the same information as written in the RFC. I'm actually half thinking about doing this myself because I already have quite a bit of data about different numbering plans in our database but it's extensive for some countries and incomplete for others although this is where grass root efforts get their power from. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 02:22:43 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1DC3A6BEA; Thu, 3 Apr 2008 02:22: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 F12C73A6BEA for ; Thu, 3 Apr 2008 02:22:42 -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 W9nQaEBHTy9f for ; Thu, 3 Apr 2008 02:22:41 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 001383A6868 for ; Thu, 3 Apr 2008 02:22:40 -0700 (PDT) Received: from [81.149.244.44] (account jim HELO [172.16.1.60]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 271043; Thu, 03 Apr 2008 10:22:42 +0100 In-Reply-To: <47F492E3.1020906@e164.org> References: <47F492E3.1020906@e164.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <67370070-9F1E-41AA-8600-256CD97D0C98@rfc1035.com> From: Jim Reid Date: Thu, 3 Apr 2008 10:21:39 +0100 To: Duane X-Mailer: Apple Mail (2.753) Cc: "enum@ietf.org" Subject: [Enum] sales pitches for alternate trees X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Apr 3, 2008, at 09:18, Duane wrote: > I haven't seen dns request stats on e164.arpa, but last time they were > announced e164.org was getting more. Please stop this "my tree's bigger than yours" childishness. Or at least take it somewhere other than this list. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 02:27:26 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158BD3A6BEB; Thu, 3 Apr 2008 02:27: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 703833A6939 for ; Thu, 3 Apr 2008 02:27:13 -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 BCDMcbzKE0j7 for ; Thu, 3 Apr 2008 02:27:07 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id D430E28C5A9 for ; Thu, 3 Apr 2008 02:25:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,597,1199664000"; d="scan'208";a="54984" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 03 Apr 2008 10:26:00 +0100 In-Reply-To: <47F492E3.1020906@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: Thu, 3 Apr 2008 10:25:58 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/04/2008 10:25:59 AM, Serialize complete at 03/04/2008 10:25:59 AM Cc: enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 don't think it is technically feasible, sorry still haven't done > testing but I can see where it would fail immediately without testing as > written in the RFC. To get routing data and prefix lengths or hints at > the same time without breaking other things such as wild card records as > the most specific entry would block the wild card. > > It wouldn't matter I don't think, due to the technical issue alone above > I think there is no way to avoid multiple packets of some description so > you might be better off almost writing a new service rather then trying > to bolt it onto DNS for no benefit. As documented in the draft this is known to be specifically incompatible with wildcards. In the NICC specifcation for the UK Central Numbering Database wildcards are not used at intermediate nodes (i.e, to represent number blocks). They are only used at leaf-nodes, to support over-dialling (i.e. sending too many digits). Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 02:57:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0BA3A6C97; Thu, 3 Apr 2008 02:57: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 5D3D23A68DB for ; Thu, 3 Apr 2008 02:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 Uk2TPzS3fiHj for ; Thu, 3 Apr 2008 02:57: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 4AB1C3A6C97 for ; Thu, 3 Apr 2008 02:57:31 -0700 (PDT) Received: from [192.168.100.101] (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 4E66C5AC364; Thu, 3 Apr 2008 20:57:33 +1100 (EST) Message-ID: <47F4AA09.6040302@e164.org> Date: Thu, 03 Apr 2008 19:57:29 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" , Jim Reid References: <47F492E3.1020906@e164.org> <67370070-9F1E-41AA-8600-256CD97D0C98@rfc1035.com> In-Reply-To: <67370070-9F1E-41AA-8600-256CD97D0C98@rfc1035.com> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] How does one measure success? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 wrote: > On Apr 3, 2008, at 09:18, Duane wrote: >> I haven't seen dns request stats on e164.arpa, but last time they were >> announced e164.org was getting more. > > Please stop this "my tree's bigger than yours" childishness. Or at > least take it somewhere other than this list. You are taking me out of context, the intention was to make his statement less abstract because he never made any frame reference as what success could be measured by at all. Ok, so I'll turn this round and ask you, in your opinion is there any frame of reference that could be used based on his original statement that e164.arpa wasn't a success without comparing it? If it is or isn't, what frame of reference would you use to make the claim one way or the other? Some made the claim years ago that IPv6 was a success. It's now years later and I believe none of the fortune 500 companies have AAAA records on their main website addresses, but that is only one way to judge success and another would be the number of subnets actively seen in BGP tables, or actively seen by some stats company. I would like your opinion on this, hopefully this isn't taken in a facetious way like my last. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 03:01:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFF528C58F; Thu, 3 Apr 2008 03:01: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 B3F2C28C1E6 for ; Thu, 3 Apr 2008 03:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 b6CHM2Gwyb8N for ; Thu, 3 Apr 2008 03:01: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 31B5028C13E for ; Thu, 3 Apr 2008 03:00:00 -0700 (PDT) Received: from [192.168.100.101] (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 C0A655AC366 for ; Thu, 3 Apr 2008 21:00:02 +1100 (EST) Message-ID: <47F4AAA0.7070207@e164.org> Date: Thu, 03 Apr 2008 20:00:00 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > As documented in the draft this is known to be specifically incompatible > with wildcards. > > In the NICC specifcation for the UK Central Numbering Database wildcards > are not used at intermediate nodes (i.e, to represent number blocks). They > are only used at leaf-nodes, to support over-dialling (i.e. sending too > many digits). If it breaks existing RFCs, and you are mostly planning to use it privately or in infrastructure enum would an X- type, and no RFC on it be more applicable? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 03:16:01 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED6928C5BA; Thu, 3 Apr 2008 03:16: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 5505E28C4FA for ; Thu, 3 Apr 2008 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, FRT_PROFILE2=1.981, 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 yQN6H7F5NGZj for ; Thu, 3 Apr 2008 03:15:59 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 40A4F28C469 for ; Thu, 3 Apr 2008 03:14:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,597,1199664000"; d="scan'208";a="52443" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Apr 2008 11:14:57 +0100 In-Reply-To: <47F492E3.1020906@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: Thu, 3 Apr 2008 11:14:57 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/04/2008 11:14:57 AM, Serialize complete at 03/04/2008 11:14:57 AM Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > > > Like it or not, for now at least it seems that private ENUM has been > > somewhat more successful than public ENUM. > > I haven't seen dns request stats on e164.arpa, but last time they were > announced e164.org was getting more. In any case I see this useful for a > lot of VoIP and non-VoIP applications even if the primary beneficiary at > this stage would be VSPs and proficient home users at this stage. Duane, My point about private ENUM vs public ENUM wasn't intended to be about the size of the databases - I was hurrying as I had to catch a train. What I was trying to say is that in private ENUM the semantics are often not identical to those of public ENUM. In particular, Richard's assertion that RFC3761 lookups should only be done on complete numbers need not apply. To answer Lawrence's question about why this has been raised again: this is the proposed solution for a real application - UK number portability. In another mail you've just asked why not 'X-'. Say another country decided that 'Send-N' style data was a good idea for their portablity database, and then in the future multiple countries decide they'd like to intermesh their portability databases so that international calls to ported numbers go directly to the recipient CP. I think it would make sense for there to be a common standard for this. I'd also counter (re: the wildcard issue) that this does not *break* other RFCs. If your ENUM tree has to use wildcards, then so be it, go ahead and use them. This draft supports an optimisation strategy for overlapped dialling, not a requirement. As it happens the wildcard issue is tied in with the relative vs absolute question that Otmar raised. I'll think further about that, and consult with my associates at NICC. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 03:30:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365573A69C9; Thu, 3 Apr 2008 03:30: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 B47013A6B68 for ; Thu, 3 Apr 2008 03:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 ZFDNxrlrvxwL for ; Thu, 3 Apr 2008 03:30:28 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id A14133A68DB for ; Thu, 3 Apr 2008 03:30:02 -0700 (PDT) Received: from [192.168.100.101] (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 18B015AC366 for ; Thu, 3 Apr 2008 21:30:04 +1100 (EST) Message-ID: <47F4B1A9.8000700@e164.org> Date: Thu, 03 Apr 2008 20:30:01 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > In another mail you've just asked why not 'X-'. Say another country > decided that 'Send-N' style data was a good idea for their portablity > database, and then in the future multiple countries decide they'd like to > intermesh their portability databases so that international calls to > ported numbers go directly to the recipient CP. I think it would make > sense for there to be a common standard for this. Exactly, so why break existing standards which has the future potential of causing such problems? To date I know of 2 cases where wild cards are useful, although they are really the same case just on different scales. Firstly where a large Tier 1 carrier has a large block of numbers and delegates these numbers out to a smaller carrier, and the smaller carrier delegates single numbers out to end users. In both cases both carriers have wild card records in a zone and so does the end user and the most specific record is returned. I realise the above cases can be handled with NS records at each successive level and should still work with your draft, but a number of countries that have evaluated or are evaluating e164.arpa are looking at the option of a single zone for faster lookups. As I keep saying I see how this is so useful for a lot of reasons, I just don't see any benefit in doing it via DNS verses some other protocol or method. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 04:36:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C2428C64C; Thu, 3 Apr 2008 04:36: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 8B06328C149 for ; Thu, 3 Apr 2008 04:36: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=[AWL=-0.001, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 RikY0HjWJFl3 for ; Thu, 3 Apr 2008 04:36:31 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 434C128C5C9 for ; Thu, 3 Apr 2008 04:36:29 -0700 (PDT) Received: from [81.149.244.44] (account jim HELO [172.16.1.60]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 271050 for enum@ietf.org; Thu, 03 Apr 2008 12:36:32 +0100 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <47F481C1.60805@e164.org> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> Message-Id: From: Jim Reid Date: Thu, 3 Apr 2008 12:35:28 +0100 To: "enum@ietf.org WG" X-Mailer: Apple Mail (2.753) Subject: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Apr 3, 2008, at 08:05, Duane wrote: > If not ENUM, then where does this best fit? IMO the issue of putting numbering plan information in the DNS is best solved with a new DNS RR type that's designed for that specific purpose and probably not with a NAPTR. So that probably means writing up something for the dnsext 2929bis process. How that hypothetical new RRtype could be used in e164.arpa is something that this WG could pick up. However this draft is deeply flawed. There are many problems: [1] It is simply unacceptable to say this NAPTR service type MUST NOT be used with a wildcard. This violates DNS fundamentals: all RRtypes are the same and the same semantics apply to them wrt wildcard processing and the likes. [Well, let's not go down the wildcard SOA and NS ratholes.] In fact it's worse than that because the restriction on whether a wildcard can be used or not depends on a *subtype* of an RRtype. This is very bad. Although I am no fan of wildcard DNS labels, it makes no sense to say "wildcards are OK for this RRtype but not that RRtype". It's even worse to say "wildcards can be used for these NAPTR service types, but not for these other ones". It's also exceptionally bad protocol design to make that a requirement. [2] The draft says nothing about how a client should behave when there are many of these proposed send-n (sub) service types and what they would mean. Suppose a lookup returns: .... NAPTR 10 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/5-6!" . .... NAPTR 10 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/3-9!" . .... NAPTR 20 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/1-5!" . .... NAPTR 20 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/4-7!" . .... NAPTR 20 30 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/6-9!" . What does this mean and how are clients and applications expected to behave? For extra bonus points, add in funky regexp substitutions instead of a boring "!^.*$!". :-) And what if there are other E2U+pstndata:send-n NAPTRs higher up the tree that conflict with these entries? Does a E2U+pstndata:send-n NAPTR for e164.arpa covering a 15 digit number over-ride one at 1.2.3.4.5.6.7.8.9.e164.arpa? Which is definitive? [3] The hierarchical structuring of E.164 numbers and the DNS means the scheme as proposed is vulnerable to all sorts of nasties. IIUC introducing one of these "E2U+pstndata:send-n" at the apex of the tree could nuke all the others at any leaf nodes in the tree. Suppose someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at the zone apex. It's game over. Any local or national dialling plan info that was submitted will never be found even though it's in the DNS because clients would have picked up the entry at the apex which tells them not to go looking for more localised dialling information. And if one of these NAPTRs gets inserted at a higher node of the tree, it can break clients who depend on local dial plan info that was stored lower down. That violates another DNS fundamental. Apart from delegations and maybe DNSSEC, nothing that goes into a parent zone should have any impact on what's in a child zone or on the responses from the DNS. And when we're not talking about delegations, an RR for some domain should have no impact on any RRs at any subdomains. [4] The concept of using the DNS to store numbering plan information is a good one. How it's been proposed here is broken. As is the application of that proposal IMO. For ENUM, the lookup is done on a complete digit string. Hitting the call button on a mobile phone is analagous in ENUM to "lookup the number that's just been typed". An ENUM lookup only takes place once the full number -- for some definition of full number -- has been dialled and translated into a domain name. To do the equivalent for overlapped dialling, a DNS lookup would be done for each digit in the number as it was typed or dialled until the client hits one of these n-send service types that has info about the number that's being dialled. I just don't see the point. Any device that has the intelligence to do a DNS lookup probably already has some sort of directory/call routing/address book capability and would be able to do The Right Thing when something dialled 3 or 4 digits on a steam phone or whatever. To my mind, a cleaner scenario would be for numbering plan info to be stored in the DNS using an RRtype that was designed for that purpose. Clients like SIP servers and SBCs could query for this at start up and maybe have to navigate through a bunch of these RRs at different points of the tree. Once that's been done, they can configure themselves with information about any local dialling plans that are revelant. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 04:56:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2413B28C68D; Thu, 3 Apr 2008 04:56: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 A7A0728C68D for ; Thu, 3 Apr 2008 04:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 KEfd02-xCDDm for ; Thu, 3 Apr 2008 04:56:54 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 9AEF628C5C9 for ; Thu, 3 Apr 2008 04:56:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,598,1199664000"; d="scan'208";a="55498" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 03 Apr 2008 12:56:58 +0100 In-Reply-To: To: Jim Reid MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 3 Apr 2008 12:56:55 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 03/04/2008 12:56:57 PM, Serialize complete at 03/04/2008 12:56:57 PM Cc: enum@ietf.org Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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, I'm at NICC at the moment and will see what others have to say before replying to the rest of your comments. Re: this one, though: > [2] The draft says nothing about how a client should behave when > there are many of these proposed send-n (sub) service types and what > they would mean. Suppose a lookup returns: I had already spotted that one and covered it in my working copy. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 08:02:42 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C1F28C6C8; Thu, 3 Apr 2008 08:02: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 189FB28C5FB for ; Thu, 3 Apr 2008 08:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lUGGBm7eYtst for ; Thu, 3 Apr 2008 08:02:40 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 7F8C528C6C8 for ; Thu, 3 Apr 2008 08:02:34 -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 m33F1ari030047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Apr 2008 07:01:37 -0800 From: "Richard Shockey" To: References: <20080401020001.AB9C13A6DC4@core3.amsl.com> In-Reply-To: <20080401020001.AB9C13A6DC4@core3.amsl.com> Date: Thu, 3 Apr 2008 11:02:16 -0400 Message-ID: <0e9001c8959b$b57348c0$2059da40$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciTm/wrWvRvOJeuQR20nWMcGc7iIwB/5vZw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] I-D Action:draft-ietf-enum-3761bis-03.txt - WG Consensus needed.... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Chair hat ON ... Are we ready to go to WGLC on this?? > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, March 31, 2008 10:00 PM > To: i-d-announce@ietf.org > Cc: enum@ietf.org > Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-03.txt > > 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 : The E.164 to Uniform Resource Identifiers > (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) > Author(s) : S. Bradner, et al. > Filename : draft-ietf-enum-3761bis-03.txt > Pages : 22 > Date : 2008-03-31 > > This document discusses the use of the Domain Name System (DNS) for > the storage of E.164 numbers, and for resolving them into URIs that > can be used for (for example) telephony call setup. This document > also describes how the DNS can be used to identify the services > associated with an E.164 number. This document obsoletes RFC 3761. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-03.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 enum-bounces@ietf.org Thu Apr 3 11:18:49 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70BC23A6F87; Thu, 3 Apr 2008 11:18: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 BA8753A6F87 for ; Thu, 3 Apr 2008 11:18:47 -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 ySDq-FcbfL21 for ; Thu, 3 Apr 2008 11:18:46 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 1978A3A6F7C for ; Thu, 3 Apr 2008 11:18:45 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 96Hc1Z0070mv7h05200300; Thu, 03 Apr 2008 18:17:42 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 96Jn1Z00502AVH03X00000; Thu, 03 Apr 2008 18:18:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=ezdYQFM2Z3nlvP67Db4A:9 a=Cc0nQjRqCClq1EsrKXQA:7 a=yD-Kv4f2HmKw9aJladZbWiBP9GIA:4 a=oqs56FR1YJwA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m33IIlEA006855 for ; Thu, 3 Apr 2008 13:18:47 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m33IIlAK006851; Thu, 3 Apr 2008 13:18:47 -0500 Date: Thu, 3 Apr 2008 13:18:47 -0500 Message-Id: <200804031818.m33IIlAK006851@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Ray.Bellis@nominet.org.uk) References: Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Some technical points: It seems undesirable to not allow the send-n record to be usable as a wildcard. The reason is that if one has a partial dial string that has not already been processed for send-n information, the only way to check if there is a relevant send-n record is to do DNS lookups on all prefixes of the string. That results in a lot of DNS lookups, which is what the send-n mechanism was to avoid in the first place. I am not familiar with the details of DNS wildcards, though, so there may be no way to act on this concern. The second issue is the use of the maximum number of digitsmax -- if the owner of a higher-level node sets digitsmax, it can prevent the delegated owner of a subtree from using more digits. Or rather, the subtree can use more digits as long as the caller doesn't attempt to use send-n to determine the end of the dial string. Indeed, it's not clear that digitsmax saves DNS queires in any practical case. So maybe digitsmax should be removed. Dale _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Apr 3 12:16:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212D73A6C52; Thu, 3 Apr 2008 12:16: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 0F30A28C2FB for ; Thu, 3 Apr 2008 12:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 GvghW1v--cUs for ; Thu, 3 Apr 2008 12:16:05 -0700 (PDT) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id 151AF3A6D0C for ; Thu, 3 Apr 2008 12:16:04 -0700 (PDT) Received: from core.dnss.ec (core.dnss.ec [82.94.105.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id A68F32D498 for ; Thu, 3 Apr 2008 21:16:06 +0200 (MEST) Message-Id: <9C9A1F1F-6F8A-48A6-9C51-BC4F1A5CAFA8@dnss.ec> From: Roy Arends To: "enum@ietf.org WG" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 21:16:05 +0200 References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Apr 3, 2008, at 1:35 PM, Jim Reid wrote: > On Apr 3, 2008, at 08:05, Duane wrote: >> If not ENUM, then where does this best fit? > > IMO the issue of putting numbering plan information in the DNS is > best solved with a new DNS RR type that's designed for that specific > purpose and probably not with a NAPTR. So that probably means writing > up something for the dnsext 2929bis process. How that hypothetical > new RRtype could be used in e164.arpa is something that this WG could > pick up. > > However this draft is deeply flawed. There are many problems: > > [1] It is simply unacceptable to say this NAPTR service type MUST NOT > be used with a wildcard. Of course it is acceptable. Technically you could have a wildcard here, but it just makes no sense doesn't it? This record is at that position solely because it assumes a number of labels. That assumption only holds when its owner name is not a wildcard. Maybe a better wording would be "NOT RECOMMENDED". > This violates DNS fundamentals: all RRtypes > are the same and the same semantics apply to them wrt wildcard > processing and the likes. [Well, let's not go down the wildcard SOA > and NS ratholes.] In fact it's worse than that because the > restriction on whether a wildcard can be used or not depends on a > *subtype* of an RRtype. This is very bad. This draft is an -00 version, and I'm sure this section is meant as an operations guideline, not as pure core protocol codex. It is a "Consideration" as the title of that specific section reveals. Like a sticker that warns against drying a cat in a microwave. Of course, it is a free world (mostly), and technically you could stick your cat in your microwave. > [3] The hierarchical structuring of E.164 numbers and the DNS means > the scheme as proposed is vulnerable to all sorts of nasties. IIUC > introducing one of these "E2U+pstndata:send-n" at the apex of the > tree could nuke all the others at any leaf nodes in the tree. Suppose > someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at > the zone apex. It's game over. Again, isn't that just a silly config mistake that one should avoid? Roy _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From hknqmmcom5@hknqmm.com Thu Apr 3 15:11:05 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 9B7373A6B87 for ; Thu, 3 Apr 2008 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.42 X-Spam-Level: *** X-Spam-Status: No, score=3.42 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DEAR_SOMETHING=1.605, J_CHICKENPOX_65=0.6, RELAY_IS_203=0.994, SARE_RMML_Stock19=0.22] 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 f58rmecGARsF for ; Thu, 3 Apr 2008 15:11:04 -0700 (PDT) Received: from hknet-202.scicube.com (hknet-202.scicube.com [203.169.145.204]) by core3.amsl.com (Postfix) with ESMTP id 17F8E3A6BFB for ; Thu, 3 Apr 2008 15:11:03 -0700 (PDT) Received: from apache by hknet-202.scicube.com with local (Exim 4.68) (envelope-from ) id 1JhTiU-0000ZV-BK for enum-archive@ietf.org; Fri, 04 Apr 2008 01:59:16 +0800 To: enum-archive@ietf.org Subject: Re : Investment Proposal . X-PHP-Script: www.hknqmm.com/bbs//skin/zero_vote/error.php for 192.168.0.228, 66.36.223.154 From: John C. Taylor Reply-To: johntaylor002@hotmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Fri, 04 Apr 2008 01:59:14 +0800 Dear Sir/Madam, I am Mr.John Taylor,Funds manager, Fidelity International Investments, The World Largest Funds management with over 1.2 Trillion GBP Capital Investment Funds.Nevertheless,as Fidelity Funds Manager, I handle all our investors Direct Capital Funds and secretly extract 3.2% Excess Maximum Return Capital Profit(EMRCP)per annum on each of investor's Magellan Capital Funds. As an expert, I have made over 49.8million GBP from the investor's EMCRP and here by looking for some one to trust who can stand as an investor to receive the funds as annual Investment Proceeds from Fidelity Magellan Capital Funds. All confirm able documents to back up this claim will be made available to you prior to your acceptance. Meanwhile, I have worked out the strategies and technicalities where the funds can be claimed in any of our 6 clearing houses without any hitch .Our sharing ratio will be 55-40 while 5% will be for expenses during the process of transaction. Should incase you are interested; please email me your direct telephone number for discussion of this deal in further details. Sincerely, Mr.John Taylor. Funds Manager Phone:+447011138798. From enum-bounces@ietf.org Fri Apr 4 03:11:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0153A6E1A; Fri, 4 Apr 2008 03:11: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 B819C3A6DF5 for ; Fri, 4 Apr 2008 03:11:26 -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 93VYsbE78gW6 for ; Fri, 4 Apr 2008 03:11:25 -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 0484028C38C for ; Fri, 4 Apr 2008 03:10:05 -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 m34AA0ga019195Fri, 4 Apr 2008 10:10:08 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Jhide-000CI8-00; Fri, 04 Apr 2008 10:55:14 +0100 Date: Fri, 4 Apr 2008 10:55:14 +0100 From: "Clive D.W. Feather" To: Duane Message-ID: <20080404095514.GN35978@finch-staff-1.thus.net> References: <47F4B1A9.8000700@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47F4B1A9.8000700@e164.org> User-Agent: Mutt/1.5.3i Cc: "enum@ietf.org" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > As I keep saying I see how this is so useful for a lot of reasons, I > just don't see any benefit in doing it via DNS verses some other > protocol or method. The big benefit is that, given something looking like a phone number, you do *one* lookup and get back either the full ENUM record or the send-n record telling you that the number is incomplete. With your approach, whenever the device has been given a full number, it has to do two separate lookups. That's a extra round trip. -- 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 Apr 4 03:11:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3E28C38C; Fri, 4 Apr 2008 03:11: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 C134128C240 for ; Fri, 4 Apr 2008 03:11:26 -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 Pg49G9XaIBTh for ; Fri, 4 Apr 2008 03:11:25 -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 DABC628C2C6 for ; Fri, 4 Apr 2008 03:10:04 -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 m34AA0gZ019195Fri, 4 Apr 2008 10:10:07 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhifR-000CLs-00; Fri, 04 Apr 2008 10:57:05 +0100 Date: Fri, 4 Apr 2008 10:57:05 +0100 From: "Clive D.W. Feather" To: Richard Shockey Message-ID: <20080404095704.GO35978@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <029101c8952c$b4eed5f0$1ecc81d0$@us> User-Agent: Mutt/1.5.3i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, 'Lawrence Conroy' , "'PFAUTZ, PENN L, ATTCORP'" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 said: > Lawrence I generally agree with the thrust of your analysis. I find it very > difficult to support the use of 3761 for digit analysis. 3761 was designed > to query on the full E.164 string not a partial string. We would be going > down a rat hole we do not want to go, especially now. > > ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The > digit strings must be fully formed in advance before query not during. You've declared that to be the case, but there's no a priori reason why it has to be true. In other words, what is the problem with extending 3761 to allow the interior nodes of the tree to contain useful information? -- 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 Apr 4 03:11:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A590328C3CF; Fri, 4 Apr 2008 03:11: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 CDE7D28C2A9 for ; Fri, 4 Apr 2008 03:11:26 -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 tTSprx8TZzZ9 for ; Fri, 4 Apr 2008 03:11:25 -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 610DD28C398 for ; Fri, 4 Apr 2008 03:10:08 -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 m34AA6DN019365Fri, 4 Apr 2008 10:10:12 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhiN5-000Buz-00; Fri, 04 Apr 2008 10:38:07 +0100 Date: Fri, 4 Apr 2008 10:38:07 +0100 From: "Clive D.W. Feather" To: Otmar Lendl Message-ID: <20080404093807.GL35978@finch-staff-1.thus.net> References: <47F4900D.4080609@nic.at> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47F4900D.4080609@nic.at> User-Agent: Mutt/1.5.3i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 said: > Your definition of the min and max fields are relative to the location > of the NAPTR record: > > The 'digitsmin' field of the data MUST correspond to the minimum > number of additional digits to be dialled, relative to the current > record, which might result in reaching a full ENUM record in the ENUM > database. > > > Wouldn't it be easier to use absolute values here? No. (1) This record corresponds to equivalent functionality in ISUP, which uses the relative case. (2) Making it relative means that the record value depends only on records lower down the tree, not where the record is in the tree. If it's absolute, then moving a sub-tree could alter the required value. For example, my home telephone exchange has changed over the years from +44 954 8xxxx to +44 954 78xxxx to +44 1954 78xxxx The latter change also involved an overlap period. Under this proposal, the send-n record corresponding to the xxxx is "pstndata:send-n/4-4" in all three cases. With your proposal, it would have to alter from: pstndata:send-n/10-10 to pstndata:send-n/11-11 to pstndata:send-n/12-12 (3) The present proposal matches what the device consuming the record actually needs to do. The above send-n record could be reached after I dial any of: 78 0195478 0044195478 In these three cases, the device needs a total of 6, 11, or 14 digits, but in each case your proposal means it gets a record saying 12 digits. The original proposal says it needs to get 4 more digits, which is always correct. -- 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 Apr 4 03:11:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D4C28C102; Fri, 4 Apr 2008 03:11: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 9B66028C40C for ; Fri, 4 Apr 2008 03:11: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=[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 WSbVz1gOvj+s for ; Fri, 4 Apr 2008 03:11:25 -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 E2FD828C391 for ; Fri, 4 Apr 2008 03:10:07 -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 m34AA6DK019365Fri, 4 Apr 2008 10:10:10 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhiYV-000C8D-00; Fri, 04 Apr 2008 10:49:55 +0100 Date: Fri, 4 Apr 2008 10:49:55 +0100 From: "Clive D.W. Feather" To: Paul Kyzivat Message-ID: <20080404094955.GM35978@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47F41276.30404@cisco.com> User-Agent: Mutt/1.5.3i Cc: "enum@ietf.org >> enum@ietf.org" , Duane Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Paul Kyzivat said: > This would be good *if* we could be assured that there would be enough > public ENUM entries to define the endpoint of all dial strings. No. If there aren't any end-point records in the relevant tree, then it doesn't matter whether send-n gives you the right answer or not. Suppose that a particular numbering plan has numbers of the form: 123456x 123457xx If it was fully populated with end-user records, then: at the 5 node, there would be a record send-n/2-3 at the 6 node, there would be a record send-n/1-1 at the 7 node, there would be a record send-n/2-2 Now suppose that the only public ENUM entry in this tree is for 1234568. It doesn't matter whether the entry at the 5 node says send-n/2-2 or send-n/2-3. If it says the former, then after dialling 1234579, the device will look for records and get none back even though the wrong number of digits have been dialled. But even if it waited for the next digit, that wouldn't help. In the converse case where the only records are for 123457xx, the entry at the 5 node might say send-n/3-3. This is slightly more problematic if the user dials 1234560, but *only* if you're using the ENUM database to determine when to stop accepting digits. In this situation, you need to ensure that the send-n records are correct or be prepared to timeout dialling. Ray, it might be worth adding something on this point of using the data to determine when a number is complete even though there are no records in the tree. > I guess each device must at least know how to get to the country level. > After that, there ought to at least be one of these entries for the > country code. For each country there ought to be either a fixed length > or a range. If a range, then there ought to be an entry for each string > of length equal to the minimum of the range, which narrows it down. True. However, in reality a device might have received more than the minimum number of digits before querying. So you need to fill in the gaps as well. -- 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 Apr 4 03:32:00 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A7B3A6E31; Fri, 4 Apr 2008 03:32: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 7C5C93A6DEF for ; Fri, 4 Apr 2008 03:31: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=[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 jTdZB7I-RsQS for ; Fri, 4 Apr 2008 03:31:57 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.68]) by core3.amsl.com (Postfix) with ESMTP id 5B2A228C3B5 for ; Fri, 4 Apr 2008 03:30:25 -0700 (PDT) Received: from [81.149.244.44] (account jim HELO [172.16.1.60]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 271156; Fri, 04 Apr 2008 11:30:29 +0100 In-Reply-To: <9C9A1F1F-6F8A-48A6-9C51-BC4F1A5CAFA8@dnss.ec> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> <9C9A1F1F-6F8A-48A6-9C51-BC4F1A5CAFA8@dnss.ec> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <81D34615-6E82-4795-AC90-42357AEEBD7B@rfc1035.com> From: Jim Reid Date: Fri, 4 Apr 2008 11:29:27 +0100 To: Roy Arends X-Mailer: Apple Mail (2.753) Cc: "enum@ietf.org WG" Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Apr 3, 2008, at 20:16, Roy Arends wrote: > On Apr 3, 2008, at 1:35 PM, Jim Reid wrote: > >> On Apr 3, 2008, at 08:05, Duane wrote: >>> If not ENUM, then where does this best fit? >> >> IMO the issue of putting numbering plan information in the DNS is >> best solved with a new DNS RR type that's designed for that specific >> purpose and probably not with a NAPTR. So that probably means writing >> up something for the dnsext 2929bis process. How that hypothetical >> new RRtype could be used in e164.arpa is something that this WG could >> pick up. >> >> However this draft is deeply flawed. There are many problems: >> >> [1] It is simply unacceptable to say this NAPTR service type MUST NOT >> be used with a wildcard. > > Of course it is acceptable. We will have to disagree about that. We're both used to disagreeing with each other. :-) > Technically you could have a wildcard here, but it just makes no > sense doesn't it? There may be circumstances where a wildcard will be needed. For instance when there are other NAPTRs besides this funky send-n service type at a given owner name. Even though I despise wildcards, it's not unreasonable to have a construct like: *..e164.arpa. NAPTR ... "" .. to direct all numbers in a block to a specific end-point. Or maybe there are a bunch of wildcard NAPTRs, one for each specific service. If this scheme is deployed or needed, it can't be done if this send-n proposal goes ahead in its current form and there has to be one of these send-n NAPTRs as well. This is why I suggest a new RRtype that's specifically designed for encoding numbering schemes instead of a NAPTR. > This record is at that position solely because it assumes a number > of labels. This is also bad design. The RDATA for a resource record should not be dependent on the number of labels in the owner name. [And yes, I do know that RRSIGs have this property.] Thanks for reminding me about that so I could remind the list. :-) > Maybe a better wording would be "NOT RECOMMENDED". Maybe. But it still doesn't change the fact that it's very poor protocol design. > This draft is an -00 version, and I'm sure this section is meant as an > operations guideline, not as pure core protocol codex. An operations guidline may well be the intention. But what's written looks like "pure core protocol codex". Deployment of this NAPTR service type would prevent a core feature of the DNS from being used. Ordinarily I would rejoice about something that curtailed DNS wildcarding. But that should be an ID that gets rid of wildcarding completely, not something that tinkers with wildcard semantics for a particular NAPTR subtype. >> [3] The hierarchical structuring of E.164 numbers and the DNS means >> the scheme as proposed is vulnerable to all sorts of nasties. IIUC >> introducing one of these "E2U+pstndata:send-n" at the apex of the >> tree could nuke all the others at any leaf nodes in the tree. Suppose >> someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at >> the zone apex. It's game over. > > Again, isn't that just a silly config mistake that one should avoid? That's a gross over-simplification Roy. Firstly, a protocol which is not just vulnerable to such a silly config mistake but actually allows it to be made is broken. Now when you consider the environment where this draft is expected to be used, the ramifications of a "silly config mistake" are mind-boggling. PBXs and SBCs could be told to dial incomplete numbers. This provides additional threats besides the obvious denial of service worries. For example, a SIP server could well have a configuration rule which says "fall back to the PSTN and SS7 (=> pay real money) when the outcome of the ENUM lookup results in some sort of call completion failure". Let's also consider the impact of this "silly config mistake" when it causes calls to emergency numbers to fail. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 03:40:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6183A6D90; Fri, 4 Apr 2008 03:40: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 5FEBF3A6D01 for ; Fri, 4 Apr 2008 03:40:56 -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, NORMAL_HTTP_TO_IP=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 SHuvxoM6NCNE for ; Fri, 4 Apr 2008 03:40:55 -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 DE8AF3A6AF0 for ; Fri, 4 Apr 2008 03:40:54 -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 m34AeuY9013991Fri, 4 Apr 2008 10:40:59 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhjI5-000DIp-00; Fri, 04 Apr 2008 11:37:01 +0100 Date: Fri, 4 Apr 2008 11:37:01 +0100 From: "Clive D.W. Feather" To: Jim Reid Message-ID: <20080404103701.GP35978@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: "enum@ietf.org WG" Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > IMO the issue of putting numbering plan information in the DNS is > best solved with a new DNS RR type that's designed for that specific > purpose and probably not with a NAPTR. Sheesh. Firstly, the application is already going to be querying for NAPTR records, so this means it gets back the desired information without any more effort. Secondly, adding new RR types should be limited to major new issues that can't be met with the existing types. > [1] It is simply unacceptable to say this NAPTR service type MUST NOT > be used with a wildcard. This could be reworded, but it's still an issue. > Well, let's not go down the wildcard SOA > and NS ratholes. [...] > Although I am no fan of wildcard DNS labels, it makes no sense to say > "wildcards are OK for this RRtype but not that RRtype". Why not? What are the semantics of a wildcard SOA? As someone else said, this is a usage guide not a technical prohibition. > [2] The draft says nothing about how a client should behave when > there are many of these proposed send-n (sub) service types and what > they would mean. Suppose a lookup returns: > > .... NAPTR 10 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/5-6!" . > .... NAPTR 10 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/3-9!" . > .... NAPTR 20 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/1-5!" . > .... NAPTR 20 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/4-7!" . > .... NAPTR 20 30 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/6-9!" . > > What does this mean and how are clients and applications expected to > behave? For extra bonus points, add in funky regexp substitutions > instead of a boring "!^.*$!". :-) In both cases, "don't do that". What does it mean if I have two SOA records at the same node in a DNS tree? What does it mean if the regexp substitution in an ENUM record is "^@.*$"? The fact that a record can be misused doesn't make it a bad thing. > And what if there are other E2U+pstndata:send-n NAPTRs higher up the > tree that conflict with these entries? Does a E2U+pstndata:send-n > NAPTR for e164.arpa covering a 15 digit number over-ride one at > 1.2.3.4.5.6.7.8.9.e164.arpa? Which is definitive? Good point. Ray, this needs to be spelled out: the record lowest down the tree overrides any higher up (since it can generally be more accurate). Thus 4.4.e164.arpa would say send-n/7-10 while 0.0.5.4.4.e164.arpa would say send-n/6-6 although the earlier record implies only send-n/4-7. > [3] The hierarchical structuring of E.164 numbers and the DNS means > the scheme as proposed is vulnerable to all sorts of nasties. Not so. > IIUC > introducing one of these "E2U+pstndata:send-n" at the apex of the > tree could nuke all the others at any leaf nodes in the tree. Suppose > someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at > the zone apex. It's game over. Any local or national dialling plan > info that was submitted will never be found even though it's in the > DNS because clients would have picked up the entry at the apex which > tells them not to go looking for more localised dialling information. No it doesn't. The client picks up this record. It accepts one more digit (since digitsmin is 1) *and then does an ENUM query*. If it gets back another send-n, that overrides the 1-15. If it gets back a full record, it uses it. If it gets nothing, it accepts another digit and tries again. If it accepts 15 more digits and *still* doesn't get any records back, it signals that no record was found. The way I see these records being used is something like this: Set min to 1 and max to infinity. While max > 0 { While min > 0 { Accept another digit * On digit timeout, break from this inner loop * On overall timeout, break from the outer loop Decrement min and max (decrementing infinity has no effect) } Do a DNS lookup for NAPTR records. If you get the type you're looking for, return it. Otherwise, if you get a send-n record: { Set min to the digitsmin value. Set max to the digitsmax value, or infinity if there isn't one. } Otherwise set min to 1. } Return failure to find any record. [First attempt; there may be errors.] Ray, feel free to steal this if you think it helps. > And if one of these NAPTRs gets inserted at a higher node of the > tree, it can break clients who depend on local dial plan info that > was stored lower down. Only if the record says that the maximum number of digits is so small the lower information can't be reached. > That violates another DNS fundamental. Apart > from delegations and maybe DNSSEC, nothing that goes into a parent > zone should have any impact on what's in a child zone or on the > responses from the DNS. And when we're not talking about delegations, > an RR for some domain should have no impact on any RRs at any > subdomains. It doesn't. > To do the equivalent for overlapped dialling, a DNS > lookup would be done for each digit in the number as it was typed or > dialled until the client hits one of these n-send service types that > has info about the number that's being dialled. Right (though the device may hold an implicit top-level record of, say, "send-n/6-15"). > I just don't see the > point. Any device that has the intelligence to do a DNS lookup > probably already has some sort of directory/call routing/address book > capability and would be able to do The Right Thing when something > dialled 3 or 4 digits on a steam phone or whatever. I don't understand what you're getting at here. The user dials "78". The internal configuation of the device converts that to "+44195478" or to "+121278". Should the device do an ENUM lookup yet, or wait for more digits? How many more? Outside a few places like the NANP, this information is complex, hard to get completely correct without help, and subject to change. Keeping all of that information in every single device is a completely broken idea; the same DNS tree as the target ENUM records appears to be the obvious place. > To my mind, a cleaner scenario would be for numbering plan info to be > stored in the DNS using an RRtype that was designed for that purpose. See above. > Clients like SIP servers and SBCs could query for this at start up > and maybe have to navigate through a bunch of these RRs at different > points of the tree. It takes a *lot* of information to describe E.164. > Once that's been done, they can configure > themselves with information about any local dialling plans that are > revelant. Unless I'm misunderstanding you, this isn't particuarly about local dialling plans, it's about *national* dialling plans. Which of these numbers are genuine and which are the wrong length? +448003634083 +44800363487 +448003635291 +44800363587 On what date will the answer change? -- 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 Apr 4 03:56:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE583A6CBC; Fri, 4 Apr 2008 03:56: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 BB43B28C1E0 for ; Fri, 4 Apr 2008 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 s-MORpk-hsL1 for ; Fri, 4 Apr 2008 03:56:28 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id A837328C780 for ; Fri, 4 Apr 2008 03:56:11 -0700 (PDT) Received: from [192.168.100.101] (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 8B9595AC36B for ; Fri, 4 Apr 2008 21:56:16 +1100 (EST) Message-ID: <47F6094B.6090208@e164.org> Date: Fri, 04 Apr 2008 20:56:11 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: <47F4B1A9.8000700@e164.org> <20080404095514.GN35978@finch-staff-1.thus.net> In-Reply-To: <20080404095514.GN35978@finch-staff-1.thus.net> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > The big benefit is that, given something looking like a phone number, you > do *one* lookup and get back either the full ENUM record or the send-n > record telling you that the number is incomplete. Yes but you can't do that without breaking other DNS types so as the other person pointed out regardless if you agree with it or not you can't just pick and choose which DNS types are more important as they are all deemed to be equal. > With your approach, whenever the device has been given a full number, it > has to do two separate lookups. That's a extra round trip. I doubt you're approach will be allowed to become standardised if for no other reason it breaks other DNS types so the benefit you are trying to coax out isn't there at least won't be in RFCs. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 04:04:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387993A697A; Fri, 4 Apr 2008 04: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 E5A8F28C1D9 for ; Fri, 4 Apr 2008 04:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 jIpGFKqf3+Wk for ; Fri, 4 Apr 2008 04:04:12 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 9828F3A67F1 for ; Fri, 4 Apr 2008 04:04:12 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m34B3GqM011992; Fri, 4 Apr 2008 11:03:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m34B3GpX011991; Fri, 4 Apr 2008 11:03:16 GMT Date: Fri, 4 Apr 2008 11:03:16 +0000 From: bmanning@vacation.karoshi.com To: "Clive D.W. Feather" Message-ID: <20080404110316.GA11827@vacation.karoshi.com.> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> <20080404103701.GP35978@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080404103701.GP35978@finch-staff-1.thus.net> User-Agent: Mutt/1.4.1i Cc: "enum@ietf.org WG" , Jim Reid Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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, Apr 04, 2008 at 11:37:01AM +0100, Clive D.W. Feather wrote: > > Well, let's not go down the wildcard SOA > > and NS ratholes. > [...] > > Although I am no fan of wildcard DNS labels, it makes no sense to say > > "wildcards are OK for this RRtype but not that RRtype". > > Why not? What are the semantics of a wildcard SOA? > > As someone else said, this is a usage guide not a technical prohibition. > semantics are easy. interpretation of results are mixed. wildcard use in SOA and NS rr's is not specifed. given the variety of DNS implementations in the field, interpretation of wildcards for these RR tyeps will vary wildly, without predictable behaviour. (this from emperical evidence) if you are looking at a -usage- guide, then it is wise to stick wiht proven, well defined technologies like NAPTR. assuming of course that you want something that can be deployed/used in your lifetime. if the enum wg wants to tackle a crisp technical specification on how wildcards should behave for SOA and NS rr's - feel free to add that to the charter. when the DNS wg looked at clarification of wildcard behaviour, it specifically excluded these two RR types. --bill (who tried this out) _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 04:04:30 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930C228C27E; Fri, 4 Apr 2008 04:04: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 B9FCD28C102 for ; Fri, 4 Apr 2008 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 y77gGnvAzBPB for ; Fri, 4 Apr 2008 04:04: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 18BFE28C3DA for ; Fri, 4 Apr 2008 04:04:27 -0700 (PDT) Received: from [192.168.100.101] (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 EC3115AC36C for ; Fri, 4 Apr 2008 22:04:31 +1100 (EST) Message-ID: <47F60B3C.3050608@e164.org> Date: Fri, 04 Apr 2008 21:04:28 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org WG" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> <20080404103701.GP35978@finch-staff-1.thus.net> In-Reply-To: <20080404103701.GP35978@finch-staff-1.thus.net> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Firstly, the application is already going to be querying for NAPTR records, > so this means it gets back the desired information without any more effort. > Secondly, adding new RR types should be limited to major new issues that > can't be met with the existing types. As you pointed out, if you wanted a standardised approach across countries and some have already placed wild card records in their records for telcos, but allow end users to override the telco blocks by providing a more specific record. Send-n would break things for when a more specific record wasn't available and would also prevent these countries from standardising on your approach and would force little disconnected internet islands or worst multiple islands interconnected and disjointed. I'm sure both approaches are far from desirable. > As someone else said, this is a usage guide not a technical prohibition. Ah, but it is, you are giving people the choice of one or the other in certain situations and expressly disallowing them from using both. -- 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 - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 04:12:49 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD93428C126; Fri, 4 Apr 2008 04:12: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 2EC8C3A6B10 for ; Fri, 4 Apr 2008 04:12: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=[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 2OQbGU3b6AI0 for ; Fri, 4 Apr 2008 04:12:48 -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 2A46F3A67F1 for ; Fri, 4 Apr 2008 04:12:48 -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 m34BCnXK003002Fri, 4 Apr 2008 11:12:51 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Jhjhn-000Dr0-00; Fri, 04 Apr 2008 12:03:35 +0100 Date: Fri, 4 Apr 2008 12:03:35 +0100 From: "Clive D.W. Feather" To: Duane Message-ID: <20080404110335.GR35978@finch-staff-1.thus.net> References: <47F4B1A9.8000700@e164.org> <20080404095514.GN35978@finch-staff-1.thus.net> <47F6094B.6090208@e164.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <47F6094B.6090208@e164.org> User-Agent: Mutt/1.5.3i Cc: "enum@ietf.org" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: >> The big benefit is that, given something looking like a phone number, you >> do *one* lookup and get back either the full ENUM record or the send-n >> record telling you that the number is incomplete. > Yes but you can't do that without breaking other DNS types so as the > other person pointed out regardless if you agree with it or not you > can't just pick and choose which DNS types are more important as they > are all deemed to be equal. I still haven't seen anything saying that this breaks other DNS types. At most there is the statement not to use this with wildcards. That perhaps needs toning down, but it's advice rather than mandatory. -- 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 Apr 4 04:12:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F7128C389; Fri, 4 Apr 2008 04:12: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 2E22328C383 for ; Fri, 4 Apr 2008 04:12:52 -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 L03OSH6aTj60 for ; Fri, 4 Apr 2008 04:12:51 -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 D50E128C3DA for ; Fri, 4 Apr 2008 04:12:50 -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 m34BCnXF003002Fri, 4 Apr 2008 11:12:49 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhjgS-000DqB-00; Fri, 04 Apr 2008 12:02:12 +0100 Date: Fri, 4 Apr 2008 12:02:12 +0100 From: "Clive D.W. Feather" To: Dale.Worley@comcast.net Message-ID: <20080404110212.GQ35978@finch-staff-1.thus.net> References: <200804031818.m33IIlAK006851@dragon.ariadne.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200804031818.m33IIlAK006851@dragon.ariadne.com> User-Agent: Mutt/1.5.3i Cc: enum@ietf.org Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Dale.Worley@comcast.net said: > It seems undesirable to not allow the send-n record to be usable as a > wildcard. The reason is that if one has a partial dial string that > has not already been processed for send-n information, the only way to > check if there is a relevant send-n record is to do DNS lookups on all > prefixes of the string. That results in a lot of DNS lookups, which > is what the send-n mechanism was to avoid in the first place. If the record holds relative lengths, as currently specified, a wildcard won't work: it matches records at different levels in the tree, and these need different send-n values. To ensure that no unnecessary lookups happen, you do need to put a send-n record in every intermediate node of the tree. In practice, though, if people follow an algorithm like the one in my earlier message today, many of these won't be needed and it might be acceptable to leave the others out. However, with a fully-provisioned sub-tree, the total number of send-n records is less than 11% of the number of end records. For example, if the root contains a record "send-n/6-15", then the part of the UK tree corresponding to London contains: +4420xx send-n/6-6 37 such records +4420xxxxxxxx endpoints up to 23 million such records Even if we fill in the gaps, we get: +4420x send-n/7-7 5 such records +4420xxx send-n/5-5 273 such records +4420xxxx send-n/4-4 2395 such records +4420xxxxx send-n/3-3 23950 such records +4420xxxxxx send-n/2-2 239500 such records +4420xxxxxxx send-n/1-1 2395000 such records The last set is the only one that's significant in size, but it only grows as real data gets added (so in the absolute worse case, where exactly one number from each block of 10 is in the database, it's the same number of records as the real data). > The second issue is the use of the maximum number of digitsmax -- if > the owner of a higher-level node sets digitsmax, it can prevent the > delegated owner of a subtree from using more digits. This is a slight issue, yes. However, if the device uses subsequent send-ns to override previous ones, it can be mitigated to some extent. I accept that a certain amount of trust in the tree management is necessary. > Or rather, the > subtree can use more digits as long as the caller doesn't attempt to > use send-n to determine the end of the dial string. Indeed, it's not > clear that digitsmax saves DNS queires in any practical case. So > maybe digitsmax should be removed. It was intended as a way for the device to know that there's no point accepting more digits and digging deeper into the tree. I accept that some extra wording is probably needed. -- 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 Apr 4 04:12:55 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5309F28C423; Fri, 4 Apr 2008 04:12: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 63C9F28C423 for ; Fri, 4 Apr 2008 04:12:53 -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 DIqKGYyIHpF9 for ; Fri, 4 Apr 2008 04:12:48 -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 AC9D03A6969 for ; Fri, 4 Apr 2008 04:12: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 m34BCnXI003002Fri, 4 Apr 2008 11:12:50 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1JhjnF-000Dwk-00; Fri, 04 Apr 2008 12:09:13 +0100 Date: Fri, 4 Apr 2008 12:09:12 +0100 From: "Clive D.W. Feather" To: Lawrence Conroy Message-ID: <20080404110912.GS35978@finch-staff-1.thus.net> References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, "PFAUTZ, PENN L, ATTCORP" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Scott has released a draft of rfc3761bis-03. > NOTE WELL - this has NOT changed the applicability text of 3761 at all. > Dialing Plans are specifically excluded from ENUM. Thus before the > esteemed SIP aficionados dive in, ENUM is about numbers, not dialed > digit strings. Agreed. This isn't about dialling plans, but about incomplete E.164 numbers. These aren't the same thing. Simple example: I pick up my office phone and dial 97222. The dialling plan tells the phone to make an ENUM lookup for +44207222. Someone in the USA picks up their phone and dials 01144207222. Their phone should be looking up the same record. Dialling plans are about the difference between what the two of us dial. This proposal is about the fact that +44207222 is an incomplete number. > An ENUM client is also expected to make an ENUM query only where it > believes it has a complete E.164 number. RFC 3761 goes on to accept > that a client may not know what constitutes a valid E.164 number (some > of us call outside the NANP :). But this is circular. What you're demonstrating is that 3761bis needs to be *extended* to cope with incomplete numbers. > In principle only having a partial view of global number plans is not > good enough. The idea of provisioning every nation state's number plan > locally into every switch is surely not what was meant. ** Nor is it anything to do with this proposal. > However, it is pushing this a bit far to send out an ENUM query with a > partially collected number, in the expectation of getting back an ISUP > SND style response. This is not something the originating node > believes is a complete number - it's something it suspects isn't. Actually, it's something that it doesn't know whether it's a complete number or not. Which is why "yes it is" or "SND 4" are both sensible answers. -- 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 Apr 4 05:55:48 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5A93A6D61; Fri, 4 Apr 2008 05:55: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 D45DA3A69A1 for ; Fri, 4 Apr 2008 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 aFwyBMMYVC8L for ; Fri, 4 Apr 2008 05:55:45 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 41CE128C287 for ; Fri, 4 Apr 2008 05:55:16 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JhlRm-0004C7-00; Fri, 04 Apr 2008 14:55:10 +0200 Date: Fri, 4 Apr 2008 14:55:10 +0200 From: Otmar Lendl To: "Clive D.W. Feather" Message-ID: <20080404125510.GA16105@nic.at> Mail-Followup-To: Otmar Lendl , "Clive D.W. Feather" , Ray.Bellis@nominet.org.uk, enum@ietf.org References: <47F4900D.4080609@nic.at> <20080404093807.GL35978@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080404093807.GL35978@finch-staff-1.thus.net> User-Agent: Mutt/1.5.9i Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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/04/04 11:04, "Clive D.W. Feather" wrote: > Otmar Lendl said: > > Wouldn't it be easier to use absolute values here? The reason for my comment just was that absolute values play much better with wildcards than relative ones. > (2) Making it relative means that the record value depends only on records > lower down the tree, not where the record is in the tree. If it's absolute, > then moving a sub-tree could alter the required value. Correct. You certainly will not manually edit the zone file anyway, but instead generate it from a database. Thus the change in send-n records is just a side effect of the changes you need to make in the backend database. > For example, my home telephone exchange has changed over the years from > +44 954 8xxxx > to +44 954 78xxxx > to +44 1954 78xxxx > The latter change also involved an overlap period. > > Under this proposal, the send-n record corresponding to the xxxx is > "pstndata:send-n/4-4" in all three cases. With your proposal, it would have > to alter from: > pstndata:send-n/10-10 > to pstndata:send-n/11-11 > to pstndata:send-n/12-12 One changed send-n record as you move over 10^4 other records. > (3) The present proposal matches what the device consuming the record > actually needs to do. The above send-n record could be reached after I dial > any of: > 78 > 0195478 > 0044195478 > In these three cases, the device needs a total of 6, 11, or 14 digits, but > in each case your proposal means it gets a record saying 12 digits. The > original proposal says it needs to get 4 more digits, which is always > correct. Whoa, stop here. You're talking dial-plans now, not numbering-plans. As others have noted, we don't do dial-plans with ENUM. /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 Fri Apr 4 06:34:07 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BADC28C46D; Fri, 4 Apr 2008 06:34: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 218BE3A6E13 for ; Fri, 4 Apr 2008 06:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 FS1gQD748xel for ; Fri, 4 Apr 2008 06:34:06 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id A46E43A6D61 for ; Fri, 4 Apr 2008 06:34:05 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Jhm3U-0004Cb-00 for ; Fri, 04 Apr 2008 15:34:08 +0200 Date: Fri, 4 Apr 2008 15:34:08 +0200 From: Otmar Lendl To: enum@ietf.org Message-ID: <20080404133407.GB16105@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <029101c8952c$b4eed5f0$1ecc81d0$@us> <47F481C1.60805@e164.org> <9C9A1F1F-6F8A-48A6-9C51-BC4F1A5CAFA8@dnss.ec> <81D34615-6E82-4795-AC90-42357AEEBD7B@rfc1035.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <81D34615-6E82-4795-AC90-42357AEEBD7B@rfc1035.com> User-Agent: Mutt/1.5.9i Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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/04/04 12:04, Jim Reid wrote: > On Apr 3, 2008, at 20:16, Roy Arends wrote: > > On Apr 3, 2008, at 1:35 PM, Jim Reid wrote: > >> On Apr 3, 2008, at 08:05, Duane wrote: > > > Technically you could have a wildcard here, but it just makes no > > sense doesn't it? > > There may be circumstances where a wildcard will be needed. For > instance when there are other NAPTRs besides this funky send-n > service type at a given owner name. > > Even though I despise wildcards, it's not unreasonable to have a > construct like: > *..e164.arpa. NAPTR ... "" .. > to direct all numbers in a block to a specific end-point. Or maybe > there are a bunch of wildcard NAPTRs, one for each specific service. This is a common deployment for all countries with open numbering plans, as the organization creating these records do not necessarily know the length of all the numbers in its own block. > If this scheme is deployed or needed, it can't be done if this send-n > proposal goes ahead in its current form and there has to be one of > these send-n NAPTRs as well. This is why I suggest a new RRtype > that's specifically designed for encoding numbering schemes instead > of a NAPTR. I might be completely off here, but my dim recollection about the working of wildcards tells me that it doesn't matter one jota whether you mix wildcards of type FOO with "normal" records of type FOO or with "normal" records of type BAR. In any case, once there is *any* record at a certain sub-domain, the wildcard from above does no longer apply. (Actually, it's even worse, read RFC 4592 and look for the discussion of "empty non-terminals". We had a lot of fun with that during our I-ENUM trial.) As I see it, you can mix *..e164.arpa. NAPTR ... "" .. .e164.arpa. NAPTR ... "send-n/" .. but neither *..e164.arpa. NAPTR ... "" .. 1.2.3..e164.arpa. NAPTR ... "send-n/" .. nor *..e164.arpa. NAPTR ... "" .. 1.2.3..e164.arpa. WHATEVER ... "send-n/" .. In both cases you'd need to add 3..e164.arpa. NAPTR ... "" .. *.3..e164.arpa. NAPTR ... "" .. 2.3..e164.arpa. NAPTR ... "" .. *.2.3..e164.arpa. NAPTR ... "" .. 1.2.3..e164.arpa. NAPTR ... "" .. *.1.2.3..e164.arpa. NAPTR ... "" .. in order to get the desired resolution behaviour for the call routing. The wildcard issue is thus irrelevant to the question of whether the "send-n" application should use NAPTRs or a different RRTYPE. /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 Fri Apr 4 06:36:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7F33A6E13; Fri, 4 Apr 2008 06:36: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 27C443A696C for ; Fri, 4 Apr 2008 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=1.849, 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 NSMke1YdQm1z for ; Fri, 4 Apr 2008 06:36:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E92163A6875 for ; Fri, 4 Apr 2008 06:36:52 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 06:36:58 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m34DawRt018133; Fri, 4 Apr 2008 06:36:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m34DavTQ008990; Fri, 4 Apr 2008 13:36:58 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:36:57 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:36:57 -0400 Message-ID: <47F62F13.4000004@cisco.com> Date: Fri, 04 Apr 2008 09:37:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Clive D.W. Feather" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com> <20080402210355.GA71089@finch-staff-1.thus.net> <47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com> <20080404094955.GM35978@finch-staff-1.thus.net> In-Reply-To: <20080404094955.GM35978@finch-staff-1.thus.net> X-OriginalArrivalTime: 04 Apr 2008 13:36:57.0532 (UTC) FILETIME=[F4050FC0:01C89658] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2873; t=1207316218; x=1208180218; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20; bh=+/8392n72lX5InDYoHmjp8GbZeWMh0Vgugh1XaXmzIY=; b=MD8qO25MqnThiFUhyqyNFVkXq1ylp6FytdwRdMY+3/guSsb9Mpv1jzSa1O 8w+A0ndsDNp7ceddNV31UY8q+Y4f8Bf/VT1VzFAC2T9R2hoeDqyl2szI8lK3 N4KSrJcuxfAsBIv06hrd8l6IkqzOkZ8RF28KUiQWWWfPgQyMbXVrI=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "enum@ietf.org >> enum@ietf.org" , Duane Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > Paul Kyzivat said: >> This would be good *if* we could be assured that there would be enough >> public ENUM entries to define the endpoint of all dial strings. > > No. If there aren't any end-point records in the relevant tree, then it > doesn't matter whether send-n gives you the right answer or not. Sure it does. The phone still needs a way to figure out when enough digits have been dialed so that it can send an INVITE, even if that INVITE is going to fail. My thought here was that it doesn't appear likely that the public enum tree under country code 1 will be fully populated any time soon. But ideally all that is really needed is a single entry that says all numbers under country code 1 require 10 more digits, and it ought to be a lot easier to get that one entry. The mechanics of getting that to work are another story. Whether its technically part of enum or something else seems to be a political issue that I don't (and don't want to) understand. Paul > Suppose that a particular numbering plan has numbers of the form: > 123456x > 123457xx > If it was fully populated with end-user records, then: > at the 5 node, there would be a record send-n/2-3 > at the 6 node, there would be a record send-n/1-1 > at the 7 node, there would be a record send-n/2-2 > Now suppose that the only public ENUM entry in this tree is for 1234568. > It doesn't matter whether the entry at the 5 node says send-n/2-2 or > send-n/2-3. If it says the former, then after dialling 1234579, the device > will look for records and get none back even though the wrong number of > digits have been dialled. But even if it waited for the next digit, that > wouldn't help. > > In the converse case where the only records are for 123457xx, the entry at > the 5 node might say send-n/3-3. This is slightly more problematic if the > user dials 1234560, but *only* if you're using the ENUM database to > determine when to stop accepting digits. In this situation, you need to > ensure that the send-n records are correct or be prepared to timeout > dialling. > > Ray, it might be worth adding something on this point of using the data to > determine when a number is complete even though there are no records in > the tree. > >> I guess each device must at least know how to get to the country level. >> After that, there ought to at least be one of these entries for the >> country code. For each country there ought to be either a fixed length >> or a range. If a range, then there ought to be an entry for each string >> of length equal to the minimum of the range, which narrows it down. > > True. However, in reality a device might have received more than the > minimum number of digits before querying. So you need to fill in the gaps > as well. > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 07:13:59 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A123A6C65; Fri, 4 Apr 2008 07:13:59 -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 0623F3A6B77 for ; Fri, 4 Apr 2008 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.822 X-Spam-Level: X-Spam-Status: No, score=-4.822 tagged_above=-999 required=5 tests=[AWL=1.778, 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 p6SQTMp8inFi for ; Fri, 4 Apr 2008 07:13:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 17A543A6BFA for ; Fri, 4 Apr 2008 07:13:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,604,1199692800"; d="scan'208";a="10218629" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2008 07:14:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m34EDwLb027551; Fri, 4 Apr 2008 07:13:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m34EDw2r027565; Fri, 4 Apr 2008 14:13:58 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:13:58 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:13:57 -0400 Message-ID: <47F637BF.4050901@cisco.com> Date: Fri, 04 Apr 2008 10:14:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Clive D.W. Feather" References: <200804031818.m33IIlAK006851@dragon.ariadne.com> <20080404110212.GQ35978@finch-staff-1.thus.net> In-Reply-To: <20080404110212.GQ35978@finch-staff-1.thus.net> X-OriginalArrivalTime: 04 Apr 2008 14:13:57.0727 (UTC) FILETIME=[1F5BEEF0:01C8965E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3239; t=1207318438; x=1208182438; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-bellis-enum-send-n-00 |Sender:=20; bh=HgX5SkI6uqZk8z4J8Sgz/2xZEWU7qExKCO5acC5WNms=; b=xqOUom33FJN6m8gvpd1HSVraHXirCLRa97/QzJ1MwtFHF1XuM4KJ0Qz+9N 71x5A1OT4Mnw3EorAFG4/Z3SWx3snvFBNGoZpaXd2xLQfTqJZMYfUMv/s21a wA/G+/3xQt; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: enum@ietf.org, Dale.Worley@comcast.net Subject: Re: [Enum] draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 IMO this would be more appealing if the higher level entries (fewer digits) were authoritative at least for the minimum number of digits. Thus there would then be no further queries until at least that many digits were received. Paul Clive D.W. Feather wrote: > Dale.Worley@comcast.net said: >> It seems undesirable to not allow the send-n record to be usable as a >> wildcard. The reason is that if one has a partial dial string that >> has not already been processed for send-n information, the only way to >> check if there is a relevant send-n record is to do DNS lookups on all >> prefixes of the string. That results in a lot of DNS lookups, which >> is what the send-n mechanism was to avoid in the first place. > > If the record holds relative lengths, as currently specified, a wildcard > won't work: it matches records at different levels in the tree, and these > need different send-n values. > > To ensure that no unnecessary lookups happen, you do need to put a send-n > record in every intermediate node of the tree. In practice, though, if > people follow an algorithm like the one in my earlier message today, many > of these won't be needed and it might be acceptable to leave the others > out. > > However, with a fully-provisioned sub-tree, the total number of send-n > records is less than 11% of the number of end records. > > For example, if the root contains a record "send-n/6-15", then the part of > the UK tree corresponding to London contains: > > +4420xx send-n/6-6 37 such records > +4420xxxxxxxx endpoints up to 23 million such records > > Even if we fill in the gaps, we get: > > +4420x send-n/7-7 5 such records > +4420xxx send-n/5-5 273 such records > +4420xxxx send-n/4-4 2395 such records > +4420xxxxx send-n/3-3 23950 such records > +4420xxxxxx send-n/2-2 239500 such records > +4420xxxxxxx send-n/1-1 2395000 such records > > The last set is the only one that's significant in size, but it only grows > as real data gets added (so in the absolute worse case, where exactly one > number from each block of 10 is in the database, it's the same number of > records as the real data). > >> The second issue is the use of the maximum number of digitsmax -- if >> the owner of a higher-level node sets digitsmax, it can prevent the >> delegated owner of a subtree from using more digits. > > This is a slight issue, yes. However, if the device uses subsequent send-ns > to override previous ones, it can be mitigated to some extent. > > I accept that a certain amount of trust in the tree management is necessary. > >> Or rather, the >> subtree can use more digits as long as the caller doesn't attempt to >> use send-n to determine the end of the dial string. Indeed, it's not >> clear that digitsmax saves DNS queires in any practical case. So >> maybe digitsmax should be removed. > > It was intended as a way for the device to know that there's no point > accepting more digits and digging deeper into the tree. I accept that some > extra wording is probably needed. > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 07:17:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0647C28C47D; Fri, 4 Apr 2008 07:17:28 -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 6AE2C28C47D for ; Fri, 4 Apr 2008 07:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, 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 wK5BjJDVla1G for ; Fri, 4 Apr 2008 07:17:25 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 3B10F28C40C for ; Fri, 4 Apr 2008 07:17:25 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JhmjO-0004qg-4e; Fri, 04 Apr 2008 09:17:26 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Clive D.W. Feather'" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> Date: Fri, 4 Apr 2008 10:17:27 -0400 Message-ID: <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F62F13.4000004@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciWWPauoluFt6o7Rs23YDOnF9y4DAAA3GSQ 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, 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 think this is the crux of the matter. We do, actually, need to know the length of a TN in order to support overlapped dialing, and to distinguish when an ENUM query fails (was it no valid number, or too few digits; there is quite a difference). It's the attempt to encode that information in the actual ENUM tree that is a problem. First of all, let us recognize that this information is published by a national numbering authority. In most cases, it's reported to the ITU, and the ITU publishes the information in a bulletin. There are commercial sources of the data. Our experience with this data is that it's not accurate, and often changes are not timely. There are usually other pieces of information that accompany the number length data that would also be valuable to anyone creating routing systems. That would include valid number ranges and portability information (is the range subject to portability). The same data also often reports block assignments (i.e. blocks of numbers assigned to specific carriers), and carrier type (fixed/mobile/VoIP). I don't foresee the end of numbering authorities any time soon. Therefore it might be worthwhile for someone to standardize the way this data is reported in a manner that anyone who needed it could get it. I am not persuaded that putting it in an ENUM tree is a good idea. I think the next question to ask if you accept that standardizing is useful would be IETF or ITU? Generally, we HAVE let the ITU handle numbering. On the other hand, it's 2008 and the ITU is reporting the data incomplete and often late, and in the form of a Word file. Summarizing, two questions: 1. Do people generally agree that it really would be a good idea to standardize a way to obtain TN length and possibly other related numbering data? 2. If such a standardization effort should be undertaken, should the IETF do it? Since we're trying to close down ENUM, this would be done somewhere else I believe. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, April 04, 2008 9:37 AM To: Clive D.W. Feather Cc: enum@ietf.org >> enum@ietf.org; Duane Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Clive D.W. Feather wrote: > Paul Kyzivat said: >> This would be good *if* we could be assured that there would be enough >> public ENUM entries to define the endpoint of all dial strings. > > No. If there aren't any end-point records in the relevant tree, then it > doesn't matter whether send-n gives you the right answer or not. Sure it does. The phone still needs a way to figure out when enough digits have been dialed so that it can send an INVITE, even if that INVITE is going to fail. My thought here was that it doesn't appear likely that the public enum tree under country code 1 will be fully populated any time soon. But ideally all that is really needed is a single entry that says all numbers under country code 1 require 10 more digits, and it ought to be a lot easier to get that one entry. The mechanics of getting that to work are another story. Whether its technically part of enum or something else seems to be a political issue that I don't (and don't want to) understand. Paul > Suppose that a particular numbering plan has numbers of the form: > 123456x > 123457xx > If it was fully populated with end-user records, then: > at the 5 node, there would be a record send-n/2-3 > at the 6 node, there would be a record send-n/1-1 > at the 7 node, there would be a record send-n/2-2 > Now suppose that the only public ENUM entry in this tree is for 1234568. > It doesn't matter whether the entry at the 5 node says send-n/2-2 or > send-n/2-3. If it says the former, then after dialling 1234579, the device > will look for records and get none back even though the wrong number of > digits have been dialled. But even if it waited for the next digit, that > wouldn't help. > > In the converse case where the only records are for 123457xx, the entry at > the 5 node might say send-n/3-3. This is slightly more problematic if the > user dials 1234560, but *only* if you're using the ENUM database to > determine when to stop accepting digits. In this situation, you need to > ensure that the send-n records are correct or be prepared to timeout > dialling. > > Ray, it might be worth adding something on this point of using the data to > determine when a number is complete even though there are no records in > the tree. > >> I guess each device must at least know how to get to the country level. >> After that, there ought to at least be one of these entries for the >> country code. For each country there ought to be either a fixed length >> or a range. If a range, then there ought to be an entry for each string >> of length equal to the minimum of the range, which narrows it down. > > True. However, in reality a device might have received more than the > minimum number of digits before querying. So you need to fill in the gaps > as well. > _______________________________________________ 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 Apr 4 07:29:06 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DE728C40C; Fri, 4 Apr 2008 07:29: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 4D79C3A6A64 for ; Fri, 4 Apr 2008 07:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ySdKP7uQWNuO for ; Fri, 4 Apr 2008 07:29:03 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 4E4413A697F for ; Fri, 4 Apr 2008 07:29:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1207319347!19990846!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 13283 invoked from network); 4 Apr 2008 14:29:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 4 Apr 2008 14:29:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m34ET7rD001664 for ; Fri, 4 Apr 2008 10:29:07 -0400 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m34ESvn4001582 for ; Fri, 4 Apr 2008 10:29:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 10:28:56 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A126BB6C7@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Thread-Index: AciWWPauoluFt6o7Rs23YDOnF9y4DAAA3GSQAACdoCA= References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org><47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net><47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> From: "PFAUTZ, PENN L, ATTCORP" To: Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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'd generally concur with Brian. I'd also still like to be clear why this isn't about dialing plans (which ENUM isn't supposed to be about) as opposed to numbering plans. It seems this is only necessary for unsenderized user interfaces where the network element interacting with the user is seeking a way to determine end of dialing other than by inter-digit timeout. Since plans that allow variable length numbers may return a value that is not determinate, e.g. 5-6, the proposal wouldn't seem to work in all cases in the absence of very low level information. (I recall in discussion of open numbering plans and non-terminal NAPTRs for infrastructure ENUM it was argued that enterprises would not want to populate records a that kind of level. I'd also ask how PBXs and exchange switches achieve this function today in places with open numbering plans. Penn Pfautz -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, April 04, 2008 10:17 AM To: 'Paul Kyzivat'; 'Clive D.W. Feather' Cc: enum@ietf.org; 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 I think this is the crux of the matter. We do, actually, need to know the length of a TN in order to support overlapped dialing, and to distinguish when an ENUM query fails (was it no valid number, or too few digits; there is quite a difference). It's the attempt to encode that information in the actual ENUM tree that is a problem. First of all, let us recognize that this information is published by a national numbering authority. In most cases, it's reported to the ITU, and the ITU publishes the information in a bulletin. There are commercial sources of the data. Our experience with this data is that it's not accurate, and often changes are not timely. There are usually other pieces of information that accompany the number length data that would also be valuable to anyone creating routing systems. That would include valid number ranges and portability information (is the range subject to portability). The same data also often reports block assignments (i.e. blocks of numbers assigned to specific carriers), and carrier type (fixed/mobile/VoIP). I don't foresee the end of numbering authorities any time soon. Therefore it might be worthwhile for someone to standardize the way this data is reported in a manner that anyone who needed it could get it. I am not persuaded that putting it in an ENUM tree is a good idea. I think the next question to ask if you accept that standardizing is useful would be IETF or ITU? Generally, we HAVE let the ITU handle numbering. On the other hand, it's 2008 and the ITU is reporting the data incomplete and often late, and in the form of a Word file. Summarizing, two questions: 1. Do people generally agree that it really would be a good idea to standardize a way to obtain TN length and possibly other related numbering data? 2. If such a standardization effort should be undertaken, should the IETF do it? Since we're trying to close down ENUM, this would be done somewhere else I believe. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, April 04, 2008 9:37 AM To: Clive D.W. Feather Cc: enum@ietf.org >> enum@ietf.org; Duane Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Clive D.W. Feather wrote: > Paul Kyzivat said: >> This would be good *if* we could be assured that there would be enough >> public ENUM entries to define the endpoint of all dial strings. > > No. If there aren't any end-point records in the relevant tree, then it > doesn't matter whether send-n gives you the right answer or not. Sure it does. The phone still needs a way to figure out when enough digits have been dialed so that it can send an INVITE, even if that INVITE is going to fail. My thought here was that it doesn't appear likely that the public enum tree under country code 1 will be fully populated any time soon. But ideally all that is really needed is a single entry that says all numbers under country code 1 require 10 more digits, and it ought to be a lot easier to get that one entry. The mechanics of getting that to work are another story. Whether its technically part of enum or something else seems to be a political issue that I don't (and don't want to) understand. Paul > Suppose that a particular numbering plan has numbers of the form: > 123456x > 123457xx > If it was fully populated with end-user records, then: > at the 5 node, there would be a record send-n/2-3 > at the 6 node, there would be a record send-n/1-1 > at the 7 node, there would be a record send-n/2-2 > Now suppose that the only public ENUM entry in this tree is for 1234568. > It doesn't matter whether the entry at the 5 node says send-n/2-2 or > send-n/2-3. If it says the former, then after dialling 1234579, the device > will look for records and get none back even though the wrong number of > digits have been dialled. But even if it waited for the next digit, that > wouldn't help. > > In the converse case where the only records are for 123457xx, the entry at > the 5 node might say send-n/3-3. This is slightly more problematic if the > user dials 1234560, but *only* if you're using the ENUM database to > determine when to stop accepting digits. In this situation, you need to > ensure that the send-n records are correct or be prepared to timeout > dialling. > > Ray, it might be worth adding something on this point of using the data to > determine when a number is complete even though there are no records in > the tree. > >> I guess each device must at least know how to get to the country level. >> After that, there ought to at least be one of these entries for the >> country code. For each country there ought to be either a fixed length >> or a range. If a range, then there ought to be an entry for each string >> of length equal to the minimum of the range, which narrows it down. > > True. However, in reality a device might have received more than the > minimum number of digits before querying. So you need to fill in the gaps > as well. > _______________________________________________ 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 07:38:06 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B313A697F; Fri, 4 Apr 2008 07:38:05 -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 803413A697F for ; Fri, 4 Apr 2008 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.887 X-Spam-Level: X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=1.712, 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 wahUACE1z2MM for ; Fri, 4 Apr 2008 07:38:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8E6473A6946 for ; Fri, 4 Apr 2008 07:38:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,604,1199682000"; d="scan'208";a="4087193" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2008 10:38:04 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m34Ec4JR009631; Fri, 4 Apr 2008 10:38:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m34Ec43m025359; Fri, 4 Apr 2008 14:38:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:38:04 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 10:38:03 -0400 Message-ID: <47F63D66.2090909@cisco.com> Date: Fri, 04 Apr 2008 10:38:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> In-Reply-To: <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 04 Apr 2008 14:38:03.0969 (UTC) FILETIME=[7D62F310:01C89661] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6397; t=1207319884; x=1208183884; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20 |To:=20Brian=20Rosen=20; bh=QshvEgabZKO3RsbCzR7Ykrp0NaCJzQV3cvuan7Mc4NY=; b=UNwr131XQmNG4RR/0Gpt5JeBcSasgae7CFK+i+nqVL92wupfwqsnGq9uAl yDd4A6skghYg0L5pPu3x2KpcGdYJDgirEyZId4+6gu/qbirL4SMtYPwrB7/K lK2k4Ik/22; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: enum@ietf.org, "'Clive D.W. Feather'" , 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 at end... Brian Rosen wrote: > I think this is the crux of the matter. > > We do, actually, need to know the length of a TN in order to support > overlapped dialing, and to distinguish when an ENUM query fails (was it no > valid number, or too few digits; there is quite a difference). > > It's the attempt to encode that information in the actual ENUM tree that is > a problem. > > First of all, let us recognize that this information is published by a > national numbering authority. In most cases, it's reported to the ITU, and > the ITU publishes the information in a bulletin. There are commercial > sources of the data. Our experience with this data is that it's not > accurate, and often changes are not timely. > > There are usually other pieces of information that accompany the number > length data that would also be valuable to anyone creating routing systems. > That would include valid number ranges and portability information (is the > range subject to portability). The same data also often reports block > assignments (i.e. blocks of numbers assigned to specific carriers), and > carrier type (fixed/mobile/VoIP). > > I don't foresee the end of numbering authorities any time soon. Therefore > it might be worthwhile for someone to standardize the way this data is > reported in a manner that anyone who needed it could get it. I am not > persuaded that putting it in an ENUM tree is a good idea. > > I think the next question to ask if you accept that standardizing is useful > would be IETF or ITU? Generally, we HAVE let the ITU handle numbering. On > the other hand, it's 2008 and the ITU is reporting the data incomplete and > often late, and in the form of a Word file. > > Summarizing, two questions: > 1. Do people generally agree that it really would be a good idea to > standardize a way to obtain TN length and possibly other related numbering > data? We still need a *workable* solution to the overlap dialing issue. (People don't consider timers to be adequate.) This seems like the only real solution to that. > 2. If such a standardization effort should be undertaken, should the IETF do > it? Since we're trying to close down ENUM, this would be done somewhere > else I believe. If we want it available via a protocol (and I think that is far preferable to a word doc), and if it is to at least play nice with enum, then ietf seems like a suitable place. But I am not really familiar with the alternatives. Re the numbering authorities: Obviously they must have a role in this. But it is not nice if we have to wait for a national numbering authority to report that some number that was assigned to a hotel in germany now may end in either "0" or "[1-9]xxx". The reporting needs to be more direct from those who implement the behavior. Paul > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Friday, April 04, 2008 9:37 AM > To: Clive D.W. Feather > Cc: enum@ietf.org >> enum@ietf.org; Duane > Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 > > > > Clive D.W. Feather wrote: >> Paul Kyzivat said: >>> This would be good *if* we could be assured that there would be enough >>> public ENUM entries to define the endpoint of all dial strings. >> No. If there aren't any end-point records in the relevant tree, then it >> doesn't matter whether send-n gives you the right answer or not. > > Sure it does. The phone still needs a way to figure out when enough > digits have been dialed so that it can send an INVITE, even if that > INVITE is going to fail. > > My thought here was that it doesn't appear likely that the public enum > tree under country code 1 will be fully populated any time soon. But > ideally all that is really needed is a single entry that says all > numbers under country code 1 require 10 more digits, and it ought to be > a lot easier to get that one entry. The mechanics of getting that to > work are another story. Whether its technically part of enum or > something else seems to be a political issue that I don't (and don't > want to) understand. > > Paul > >> Suppose that a particular numbering plan has numbers of the form: >> 123456x >> 123457xx >> If it was fully populated with end-user records, then: >> at the 5 node, there would be a record send-n/2-3 >> at the 6 node, there would be a record send-n/1-1 >> at the 7 node, there would be a record send-n/2-2 >> Now suppose that the only public ENUM entry in this tree is for 1234568. >> It doesn't matter whether the entry at the 5 node says send-n/2-2 or >> send-n/2-3. If it says the former, then after dialling 1234579, the device >> will look for records and get none back even though the wrong number of >> digits have been dialled. But even if it waited for the next digit, that >> wouldn't help. >> >> In the converse case where the only records are for 123457xx, the entry at >> the 5 node might say send-n/3-3. This is slightly more problematic if the >> user dials 1234560, but *only* if you're using the ENUM database to >> determine when to stop accepting digits. In this situation, you need to >> ensure that the send-n records are correct or be prepared to timeout >> dialling. >> >> Ray, it might be worth adding something on this point of using the data to >> determine when a number is complete even though there are no records in >> the tree. >> >>> I guess each device must at least know how to get to the country level. >>> After that, there ought to at least be one of these entries for the >>> country code. For each country there ought to be either a fixed length >>> or a range. If a range, then there ought to be an entry for each string >>> of length equal to the minimum of the range, which narrows it down. >> True. However, in reality a device might have received more than the >> minimum number of digits before querying. So you need to fill in the gaps >> as well. >> > _______________________________________________ > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 08:57:38 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F48D3A6CEC; Fri, 4 Apr 2008 08:57: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 87A173A6899 for ; Fri, 4 Apr 2008 08:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 aWJQzkcxDGY9 for ; Fri, 4 Apr 2008 08:57:36 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 73B5A3A6BF0 for ; Fri, 4 Apr 2008 08:57:36 -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 m34FqQ6a000477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2008 07:52:27 -0800 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> In-Reply-To: <47F63D66.2090909@cisco.com> Date: Fri, 4 Apr 2008 11:53:02 -0400 Message-ID: <122101c8966b$f7e360c0$e7aa2240$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciWYWReDo323psfSD2hNM812l0aEAACVE/g Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, "'Clive D.W. Feather'" , 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 line... > > We still need a *workable* solution to the overlap dialing issue. > (People don't consider timers to be adequate.) > > This seems like the only real solution to that. > > > 2. If such a standardization effort should be undertaken, should the > IETF do > > it? Since we're trying to close down ENUM, this would be done > somewhere > > else I believe. > > If we want it available via a protocol (and I think that is far > preferable to a word doc), and if it is to at least play nice with > enum, > then ietf seems like a suitable place. But I am not really familiar > with> the alternatives. I'm told Geneva is very pleasant in the springtime. I highly recommend Le boufe rouge restaurant. Excellent French bistro food. > > Re the numbering authorities: Obviously they must have a role in this. > But it is not nice if we have to wait for a national numbering > authority > to report that some number that was assigned to a hotel in germany now > may end in either "0" or "[1-9]xxx". The reporting needs to be more > direct from those who implement the behavior. Numbering is, has been and will continue to be a nation state issue. My own sentiment is that this is a out of band data point that it will be very difficult implement as a protocol. For in country calls ..its a network element configuration issue. For out of country calls ..give the call to your termination partner and let them sort it out (a trunking decision). > > Paul > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 09:32:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91823A6A13; Fri, 4 Apr 2008 09:32: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 57B7D3A6A13 for ; Fri, 4 Apr 2008 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=1.651, 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 w7Mp-24wadsT for ; Fri, 4 Apr 2008 09:32:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1932B3A68EE for ; Fri, 4 Apr 2008 09:32:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,605,1199682000"; d="scan'208";a="4085619" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2008 12:32:08 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m34GW8eg011127; Fri, 4 Apr 2008 12:32:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m34GW8xp004894; Fri, 4 Apr 2008 16:32:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:32:07 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:32:07 -0400 Message-ID: <47F65822.5030205@cisco.com> Date: Fri, 04 Apr 2008 12:32:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Richard Shockey References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> In-Reply-To: <122101c8966b$f7e360c0$e7aa2240$@us> X-OriginalArrivalTime: 04 Apr 2008 16:32:07.0622 (UTC) FILETIME=[6C858660:01C89671] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3073; t=1207326728; x=1208190728; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20 |To:=20Richard=20Shockey=20; bh=Kwz9NmTuiUrHFfquz+cpCngdSvMF8wNiJzmndNgXDSc=; b=Fq7iCz0z0jZZrotqO7p/aJZ8lv/o3avsZZL79XO/f90uN/PEmJaWItxU0o 2pVklzOkTdJj/D2dP23ZTqqyn+jENtl70jysXVSDsPgPHBRy2OshpI2ox+Bg g10Gx/J/bx; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: enum@ietf.org, "'Clive D.W. Feather'" , 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 certainly not going to argue with a Neustar employee about the realities of deploying and managing this sort of stuff. But from a UAC perspective the solutions for variable length numbers suck. Overlap dialing is problematic at best, and timers don't give an adequate user experience. Provisioning is ok if you are deploying in a place with a simple, generally fixed length numbering plan, with few and easily knowable exceptions. But as soon as you throw in international dialing or deploy in a place with variable number lengths on anything approaching a per-number basis it doesn't work. Requirements to solve this keep coming up from marketing. A good (hypothentical) use case is: - install a sip "pbx" in a german hotel, with a short main number and longer room numbers. - connect that hotel to a sip service provider - connect some other sip clients (unaffiliated with the hotel) to the same sip SP. Let these be adapters to black phones. - try to call the desk and the rooms of the hotel from those clients. Give as good a user experience to the caller as before switching from pstn to sip on both sided. (Namely no lag after dialing the last digit before getting ringback.) - also have those clients call another hotel that is still only on the PSTN, using redundant GWs on the SP network. Again give as good a user experience as before. Paul Richard Shockey wrote: > In line... > >> >> We still need a *workable* solution to the overlap dialing issue. >> (People don't consider timers to be adequate.) >> >> This seems like the only real solution to that. >> >> > 2. If such a standardization effort should be undertaken, should the >> IETF do >> > it? Since we're trying to close down ENUM, this would be done >> somewhere >> > else I believe. >> >> If we want it available via a protocol (and I think that is far >> preferable to a word doc), and if it is to at least play nice with >> enum, >> then ietf seems like a suitable place. But I am not really familiar >> with> the alternatives. > > > I'm told Geneva is very pleasant in the springtime. I highly recommend Le > boufe rouge restaurant. Excellent French bistro food. > >> >> Re the numbering authorities: Obviously they must have a role in this. >> But it is not nice if we have to wait for a national numbering >> authority >> to report that some number that was assigned to a hotel in germany now >> may end in either "0" or "[1-9]xxx". The reporting needs to be more >> direct from those who implement the behavior. > > Numbering is, has been and will continue to be a nation state issue. My own > sentiment is that this is a out of band data point that it will be very > difficult implement as a protocol. For in country calls ..its a network > element configuration issue. > > > For out of country calls ..give the call to your termination partner and let > them sort it out (a trunking decision). > >> >> Paul >> > > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 10:28:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B4B3A6CA1; Fri, 4 Apr 2008 10:28: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 4D00A3A6CA1 for ; Fri, 4 Apr 2008 10:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.792, 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 kd6K5WU9GJlN for ; Fri, 4 Apr 2008 10:28:13 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 20F073A6C7D for ; Fri, 4 Apr 2008 10:28:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jhpi0-0004zz-Br; Fri, 04 Apr 2008 12:28:12 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Richard Shockey'" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> Date: Fri, 4 Apr 2008 13:28:13 -0400 Message-ID: <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F65822.5030205@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciWcWy/Xr1b9guSSwWuoLjjuzBtsAAB1W7A 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, "'Clive D.W. Feather'" , 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 One thing I don't think we have to do is give the black phone or black phone connected to TA a BETTER experience than they have now. Those of you in countries that allow this kind of "enterprise can define how long the number is", what is the user experience? You can route as soon as the prefix is entered. What is the user experience after that? What if there was a short or a long pause between the prefix and one of the internally consumed digits? After all, the originating switch doesn't know how many digits the enterprise uses. Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, April 04, 2008 12:33 PM To: Richard Shockey Cc: 'Brian Rosen'; enum@ietf.org; 'Clive D.W. Feather'; 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 I am certainly not going to argue with a Neustar employee about the realities of deploying and managing this sort of stuff. But from a UAC perspective the solutions for variable length numbers suck. Overlap dialing is problematic at best, and timers don't give an adequate user experience. Provisioning is ok if you are deploying in a place with a simple, generally fixed length numbering plan, with few and easily knowable exceptions. But as soon as you throw in international dialing or deploy in a place with variable number lengths on anything approaching a per-number basis it doesn't work. Requirements to solve this keep coming up from marketing. A good (hypothentical) use case is: - install a sip "pbx" in a german hotel, with a short main number and longer room numbers. - connect that hotel to a sip service provider - connect some other sip clients (unaffiliated with the hotel) to the same sip SP. Let these be adapters to black phones. - try to call the desk and the rooms of the hotel from those clients. Give as good a user experience to the caller as before switching from pstn to sip on both sided. (Namely no lag after dialing the last digit before getting ringback.) - also have those clients call another hotel that is still only on the PSTN, using redundant GWs on the SP network. Again give as good a user experience as before. Paul Richard Shockey wrote: > In line... > >> >> We still need a *workable* solution to the overlap dialing issue. >> (People don't consider timers to be adequate.) >> >> This seems like the only real solution to that. >> >> > 2. If such a standardization effort should be undertaken, should the >> IETF do >> > it? Since we're trying to close down ENUM, this would be done >> somewhere >> > else I believe. >> >> If we want it available via a protocol (and I think that is far >> preferable to a word doc), and if it is to at least play nice with >> enum, >> then ietf seems like a suitable place. But I am not really familiar >> with> the alternatives. > > > I'm told Geneva is very pleasant in the springtime. I highly recommend Le > boufe rouge restaurant. Excellent French bistro food. > >> >> Re the numbering authorities: Obviously they must have a role in this. >> But it is not nice if we have to wait for a national numbering >> authority >> to report that some number that was assigned to a hotel in germany now >> may end in either "0" or "[1-9]xxx". The reporting needs to be more >> direct from those who implement the behavior. > > Numbering is, has been and will continue to be a nation state issue. My own > sentiment is that this is a out of band data point that it will be very > difficult implement as a protocol. For in country calls ..its a network > element configuration issue. > > > For out of country calls ..give the call to your termination partner and let > them sort it out (a trunking decision). > >> >> Paul >> > > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 11:03:25 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE5428C17E; Fri, 4 Apr 2008 11: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 392A328C27E for ; Fri, 4 Apr 2008 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pmdLvBszhcBZ for ; Fri, 4 Apr 2008 11:03:20 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 9D6F828C1C0 for ; Fri, 4 Apr 2008 11:03:20 -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 m34HwM0d007055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2008 09:58:23 -0800 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> In-Reply-To: <47F65822.5030205@cisco.com> Date: Fri, 4 Apr 2008 13:58:57 -0400 Message-ID: <138501c8967d$8ef10e20$acd32a60$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciWcVMdfamFPxOuSGy4QUu2+WCT9AAA0KWg Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, "'Clive D.W. Feather'" , 'Duane' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 certainly not going to argue with a Neustar employee about the > realities of deploying and managing this sort of stuff... But anyone familiar with the realities of the E.164 plan and its national implementations would tell you exactly the same thing. There is no centralized registry describing the structure of the totality of E.164 plan. We've had the issue of various here for years especially given the structure of the German and Austrian dialing plans. The business/technical case here is self evident. The issue is do you use the DNS to reveal the structure of the national dial plan or use some out of band method to describe the structure. I understand the issue of post dial delay intimately since it also comes up in how the ENUM query is to be preformed and by what network element and if the "directory" is THE DNS or simply a IPRD (big fat cached ANS- ENUM box) located in the carrier network that has its data store fed from various forms of numbering data sources (Private ENUM). I know people hate timers but the solution proposed here is probably worse than the problem. > But from a UAC perspective the solutions for variable length numbers > suck. Overlap dialing is problematic at best, and timers don't give an > adequate user experience. Provisioning is ok if you are deploying in a > place with a simple, generally fixed length numbering plan, with few > and > easily knowable exceptions. But as soon as you throw in international > dialing or deploy in a place with variable number lengths on anything > approaching a per-number basis it doesn't work. > > Requirements to solve this keep coming up from marketing. > > A good (hypothentical) use case is: > > - install a sip "pbx" in a german hotel, with a short main number > and longer room numbers. > > - connect that hotel to a sip service provider > > - connect some other sip clients (unaffiliated with the hotel) > to the same sip SP. Let these be adapters to black phones. > > - try to call the desk and the rooms of the hotel from > those clients. Give as good a user experience to the caller > as before switching from pstn to sip on both sided. > (Namely no lag after dialing the last digit before getting > ringback.) > > - also have those clients call another hotel that is still > only on the PSTN, using redundant GWs on the SP network. > Again give as good a user experience as before. > > Paul > > Richard Shockey wrote: > > In line... > > > >> > >> We still need a *workable* solution to the overlap dialing issue. > >> (People don't consider timers to be adequate.) > >> > >> This seems like the only real solution to that. > >> > >> > 2. If such a standardization effort should be undertaken, should > the > >> IETF do > >> > it? Since we're trying to close down ENUM, this would be done > >> somewhere > >> > else I believe. > >> > >> If we want it available via a protocol (and I think that is far > >> preferable to a word doc), and if it is to at least play nice with > >> enum, > >> then ietf seems like a suitable place. But I am not really > familiar > >> with> the alternatives. > > > > > > I'm told Geneva is very pleasant in the springtime. I highly > recommend Le > > boufe rouge restaurant. Excellent French bistro food. > > > >> > >> Re the numbering authorities: Obviously they must have a role in > this. > >> But it is not nice if we have to wait for a national numbering > >> authority > >> to report that some number that was assigned to a hotel in germany > now > >> may end in either "0" or "[1-9]xxx". The reporting needs to be > more > >> direct from those who implement the behavior. > > > > Numbering is, has been and will continue to be a nation state issue. > My own > > sentiment is that this is a out of band data point that it will be > very > > difficult implement as a protocol. For in country calls ..its a > network > > element configuration issue. > > > > > > For out of country calls ..give the call to your termination partner > and let > > them sort it out (a trunking decision). > > > >> > >> Paul > >> > > > > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 11:57:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D56C3A6B97; Fri, 4 Apr 2008 11:57: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 29B6D3A6B86 for ; Fri, 4 Apr 2008 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 40Vm684l5V5Y for ; Fri, 4 Apr 2008 11:57:23 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 265E63A6F94 for ; Fri, 4 Apr 2008 11:56:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,605,1199664000"; d="scan'208";a="100338" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Apr 2008 19:56:41 +0100 In-Reply-To: <138501c8967d$8ef10e20$acd32a60$@us> 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, 4 Apr 2008 19:56:40 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/04/2008 07:56:41 PM, Serialize complete at 04/04/2008 07:56:41 PM Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > But anyone familiar with the realities of the E.164 plan and its national > implementations would tell you exactly the same thing. There is no > centralized registry describing the structure of the totality of E.164 plan. I rather thought the point of this was that in the DNS it doesn't have to be centralized :) In the future hypothetical use case of multiple countries allowing interconnection between their national portability databases [i.e. my justification for trying to standardise this] then each database administrator can publish their own portion of the E.164 numbering plan. NB: I don't currently expect to see this in public ENUM, it really is a private ENUM application. However it does have theoretical benefits in public ENUM, and several people have said the data would be useful (even if some of them aren't happy with the current proposed implementation). Hence I think it's worth making the effort to ensure that it wouldn't break anything were it to be deployed. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 17:31:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7026D3A6C4A; Fri, 4 Apr 2008 17:31: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 4A9DF3A682B for ; Fri, 4 Apr 2008 17:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LQGNpJ-xPbXR for ; Fri, 4 Apr 2008 17:31:31 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id C67243A6A77 for ; Fri, 4 Apr 2008 17:30:33 -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 m350TTqk008855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2008 16:29:31 -0800 From: "Richard Shockey" To: , References: <138501c8967d$8ef10e20$acd32a60$@us> In-Reply-To: Date: Fri, 4 Apr 2008 20:30:02 -0400 Message-ID: <0a8101c896b4$316b1480$94413d80$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciWhaQ3+rqL77kKTsiqBbAInN+jEgALionw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 rather thought the point of this was that in the DNS it doesn't have > to > be centralized :) > > In the future hypothetical use case of multiple countries allowing > interconnection between their national portability databases [i.e. my > justification for trying to standardise this] then each database > administrator can publish their own portion of the E.164 numbering > plan. But the point some of us are making is that you don't have to publish the structure of the national dial plan in the DNS. This could be a out of band process. You just need to know where to get the data. > > NB: I don't currently expect to see this in public ENUM, it really is > a private ENUM application. Like duh .. :-) However it does have theoretical benefits > in public ENUM, and several people have said the data would be useful > (even if some of them aren't happy with the current proposed > implementation). > Hence I think it's worth making the effort to ensure that it wouldn't > break anything were it to be deployed. > > Ray > _______________________________________________ > 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 Apr 4 17:59:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6D33A6AE8; Fri, 4 Apr 2008 17:59: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 A8DC03A6895 for ; Fri, 4 Apr 2008 17:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5sqEjOvLKGf5 for ; Fri, 4 Apr 2008 17:59:31 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id DCFF23A6AA0 for ; Fri, 4 Apr 2008 17:59:31 -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 m350wKrJ025322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Apr 2008 16:58:21 -0800 From: "Richard Shockey" To: Date: Fri, 4 Apr 2008 20:58:52 -0400 Message-ID: <0b1901c896b8$38955a00$a9c00e00$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0B1A_01C89696.B183BA00" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AciWkwne9tqIIcl3RP2kKPyGW8Wh5gAJSqFg 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-yu-enumservice-sms-smpp-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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_0B1A_01C89696.B183BA00 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: Friday, April 04, 2008 4:30 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-yu-enumservice-sms-smpp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. 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-00.txt Pages : 11 Date : 2008-4-3 This document registers an enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 [2] and draft-ietf-enum- enumservices-guide-07 [6] and registers a new URI type "smpp:" according to the URI registration procedure in RFC 4395 [8]. 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-enumservice-sms-smpp-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_000_0B1A_01C89696.B183BA00 Content-Type: Message/External-body; name="draft-yu-enumservice-sms-smpp-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yu-enumservice-sms-smpp-00.txt" Content-Type: text/plain Content-ID: <2008-4-4132730.I-D@ietf.org> ------=_NextPart_000_0B1A_01C89696.B183BA00 Content-Type: text/plain; name="ATT01543.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01543.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_0B1A_01C89696.B183BA00 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_0B1A_01C89696.B183BA00-- From enum-bounces@ietf.org Fri Apr 4 18:06:42 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160EA3A68D3; Fri, 4 Apr 2008 18:06: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 899403A67FE for ; Fri, 4 Apr 2008 18:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 pR-oSCSZy5IS for ; Fri, 4 Apr 2008 18:06:34 -0700 (PDT) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id B3F583A6CBE for ; Fri, 4 Apr 2008 18:06:23 -0700 (PDT) Received: from [192.168.100.101] (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 941485AC379 for ; Sat, 5 Apr 2008 12:06:32 +1100 (EST) Message-ID: <47F6D092.90005@e164.org> Date: Sat, 05 Apr 2008 11:06:26 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: "enum@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > NB: I don't currently expect to see this in public ENUM, it really is a > private ENUM application. However it does have theoretical benefits in > public ENUM, and several people have said the data would be useful (even > if some of them aren't happy with the current proposed implementation). > Hence I think it's worth making the effort to ensure that it wouldn't > break anything were it to be deployed. Since public enum was messed with in the pass to try and bolt on an infrastructure component maybe something similar could be done that would allow both public enum to still have the possibility of wild cards, while allowing send-n to be published as well without interfering as well. Just a thought. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Apr 4 22:49:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727ED3A68CD; Fri, 4 Apr 2008 22:49: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 E9B703A68CD for ; Fri, 4 Apr 2008 22:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 VxVJp3o6F-na for ; Fri, 4 Apr 2008 22:49:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 01C533A67E9 for ; Fri, 4 Apr 2008 22:49:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 5 Apr 2008 01:49:09 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 01:49:09 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" Date: Sat, 5 Apr 2008 01:48:45 -0400 Thread-Topic: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Thread-Index: AciWhbSEvOc6ikzBTnKQz4X5HsfK4wAUebBw Message-ID: References: <138501c8967d$8ef10e20$acd32a60$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "enum@ietf.org" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Howdy, I don't disagree with the points you guys are making, but I wonder if you're coming at this from the wrong angle given the relative sensitivities to ENUM-specific uses of DNS. If one of your use-cases or goals is to enable this for public ENUM, I think one way to look at this is simply as a DNS problem. Alice has asked a DNS NAPTR query, for foo.bar.com, and its server would like to tell her that NAPTR record types don't exist for foo.bar.com but may exist for *.*.foo.bar.com and *.*.*.foo.bar.com. In other words the server wants to answer differently than not-found, or with additional detail, and could answer this way for any RR type asked of it for any name. I have absolutely zero clue if that's going to help or make it worse in the IETF's view, but it's different. :) (it could easily be worse, fwiw, because it has a potential to raise a LOT of issues) I hesitated saying this, because I fear what this would mean for UNUSED's chances of getting approved, but another way to look at it is as a specific type of UNUSED scenario, obviously. Alice has asked a DNS NAPTR query for 1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all), so all you're missing is something in the resulting data URN to tell the client why. (the latest draft is an http URL, but I'm going to try to revert to a data one that is well-defined, a la pstndata) But at least you could then simply define an extension ABNF and semantics for the unused-data URN in a separate draft. It would not break UNUSED, because the unknown extension abnf in the URN would simply be ignored. If your goal is only private ENUM, but you want it publicly documented to foster interop with vendors for private use (a goal which I can certainly understand), then nothing stops you from defining it for UNUSED or your current way as an informational RFC, with clear language regarding applicability. But I still think it would be good to hash out the best way for it to be done, so that it's not specific to private use in the UK. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Apr 5 06:36:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D9C3A69E6; Sat, 5 Apr 2008 06:36: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 4D6C23A69E6 for ; Sat, 5 Apr 2008 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 vKZv75Si3MJp for ; Sat, 5 Apr 2008 06:36:17 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 2F9B33A69C9 for ; Sat, 5 Apr 2008 06:36:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ji8ZB-0000XS-Aj; Sat, 05 Apr 2008 08:36:21 -0500 From: "Brian Rosen" To: "'Hadriel Kaplan'" , References: <138501c8967d$8ef10e20$acd32a60$@us> Date: Sat, 5 Apr 2008 09:36:22 -0400 Message-ID: <02d101c89722$0b1050c0$640fa8c0@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: AciWhbSEvOc6ikzBTnKQz4X5HsfK4wAUebBwABJvV+A= 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] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 think we're tending to agree that the data is useful, and disagree on how you get it. I think we're tending to agree that even if you use private ENUM, you need the data. The question is then where to put it. I would point out that the SOURCE of the data is the number plan administrator in a country, which is distinctly different from the operator of the public enum tree, if there is one. I'd rather see a mechanism that the number plan administrator could use directly, and I'd like to avoid the delegation issues of public enum. It's really just a file. Couldn't we just define an XML data structure for that file and figure out a way to publish it? Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, April 05, 2008 1:49 AM To: Ray.Bellis@nominet.org.uk Cc: enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Howdy, I don't disagree with the points you guys are making, but I wonder if you're coming at this from the wrong angle given the relative sensitivities to ENUM-specific uses of DNS. If one of your use-cases or goals is to enable this for public ENUM, I think one way to look at this is simply as a DNS problem. Alice has asked a DNS NAPTR query, for foo.bar.com, and its server would like to tell her that NAPTR record types don't exist for foo.bar.com but may exist for *.*.foo.bar.com and *.*.*.foo.bar.com. In other words the server wants to answer differently than not-found, or with additional detail, and could answer this way for any RR type asked of it for any name. I have absolutely zero clue if that's going to help or make it worse in the IETF's view, but it's different. :) (it could easily be worse, fwiw, because it has a potential to raise a LOT of issues) I hesitated saying this, because I fear what this would mean for UNUSED's chances of getting approved, but another way to look at it is as a specific type of UNUSED scenario, obviously. Alice has asked a DNS NAPTR query for 1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all), so all you're missing is something in the resulting data URN to tell the client why. (the latest draft is an http URL, but I'm going to try to revert to a data one that is well-defined, a la pstndata) But at least you could then simply define an extension ABNF and semantics for the unused-data URN in a separate draft. It would not break UNUSED, because the unknown extension abnf in the URN would simply be ignored. If your goal is only private ENUM, but you want it publicly documented to foster interop with vendors for private use (a goal which I can certainly understand), then nothing stops you from defining it for UNUSED or your current way as an informational RFC, with clear language regarding applicability. But I still think it would be good to hash out the best way for it to be done, so that it's not specific to private use in the UK. -hadriel _______________________________________________ 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 Sat Apr 5 07:40:54 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4823A6A0B; Sat, 5 Apr 2008 07:40: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 761AF3A679C for ; Sat, 5 Apr 2008 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 aXtCRYV0cYTG for ; Sat, 5 Apr 2008 07:40:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8282D3A68A8 for ; Sat, 5 Apr 2008 07:40:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 5 Apr 2008 10:40:33 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 10:40:33 -0400 From: Hadriel Kaplan To: Brian Rosen , "Ray.Bellis@nominet.org.uk" Date: Sat, 5 Apr 2008 10:40:09 -0400 Thread-Topic: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Thread-Index: AciWhbSEvOc6ikzBTnKQz4X5HsfK4wAUebBwABJvV+AAARhU8A== Message-ID: References: <138501c8967d$8ef10e20$acd32a60$@us> <02d101c89722$0b1050c0$640fa8c0@cis.neustar.com> In-Reply-To: <02d101c89722$0b1050c0$640fa8c0@cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "enum@ietf.org" Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: Brian Rosen [mailto:br@brianrosen.net] > > The question is then where to put it. Not really, or rather it won't be enough, if it's not put into the NAPTR records some way. For closed environments that may well be enough, but for the public ENUM it would be really hard to see how any random UA is to know to get which file for which country or have the latest copy at all times, etc. So I think they would query an UNUSED or non-existant entry a lot regardless. One way to do it is using an UNUSED http url, to point to a source for the data, instead of a data url. But I don't see why it couldn't (maybe optionally) be a data url, if it were sufficiently defined. > I would point out that the SOURCE of the data is the number plan > administrator in a country, which is distinctly different from the > operator > of the public enum tree, if there is one. Yes, but that's not the case for private use, and even for public use does it prevent the operator of the public enum tree from being able to supply such "hints", or the numbering plan admin from coordinating such with the operator? IANAE. > I'd rather see a mechanism that the number plan administrator could use > directly, and I'd like to avoid the delegation issues of public enum. ESPP? ;) > It's really just a file. Couldn't we just define an XML data structure > for > that file and figure out a way to publish it? There are pros/cons to doing this in files. There is no doubt that it would be far more efficient (messaging-wise) for each UA or proxy on the planet to have a numbering plan template, for the country it makes lots of calls to, but my guess is it would be fairly impractical and unnecessary for each to have those plans for all countries, and impractical for the files to be available to all UAs/proxies. DNS has the rather nice property of lightweight just-in-time delivery with a limited scope to the node record being queried for. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Apr 5 17:17:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A99B3A6BC8; Sat, 5 Apr 2008 17:17: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 0FAEC3A6810 for ; Sat, 5 Apr 2008 17:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=2.081, 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 6TpyPfZ8zyE9 for ; Sat, 5 Apr 2008 17:17:02 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id A80533A6AA7 for ; Sat, 5 Apr 2008 17:17:01 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id AE32F89E7E; Sun, 6 Apr 2008 01:17:09 +0100 (BST) Message-Id: <52FA3718-084E-4630-A7D9-881FE48E0C35@insensate.co.uk> From: Lawrence Conroy To: james.yu@neustar.biz, Richard Shockey In-Reply-To: <0b1901c896b8$38955a00$a9c00e00$@us> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 6 Apr 2008 01:17:09 +0100 References: <0b1901c896b8$38955a00$a9c00e00$@us> X-Mailer: Apple Mail (2.919.2) Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 James, Richard, folks, many thanks for forwarding this. I was a little surprised that James didn't mention it on list. You must have beaten him to it. (i) The formatting is borked on the draft - this makes it hard to read as the text clashes with/runs into the headers. (ii) I AssUMe that the draft is intended to update RFC 4355. It should state that in the header, explain how it updates it (by adding a new sub-type), AND it should refer to RFC 4355 in the normative references. (iii) Whilst we're at it, it IS confusing to have the Enumservice & URI registration intermingled throughout the draft. The CNAM document has a MUCH clearer separation. I hope that by -07 this will be as easy to read :). (iv) It is NOT clear how SMPP fits with IMS (or doesn't). If it doesn't, then why have refs. to 3GPP IMS specs (notably 24.341 version 7.2.0)? If it does, then I'd strongly recommend referring out to the 3GPP architecture diagrams, and the reference points they specify - it made life easier in getting 4355 through its Loooooong gestation period in the IESG. From experience, you WILL need to explain how these all fit together - and frankly, I think that would be a very useful addition to the next version of the draft. (iv) Regardless of how widely it may (or may not) be implemented, if you're going to specify a URI scheme, then pointing to the protocol spec would be good: - The SMPP Forum doesn't exist any more. - The SMS Forum (into which it morphed) has also shut down. + However, its web site still has links to the specs. In the case of SMPP, it is at . ? That version appears to be later than the interim version to which the internet draft refers. (v) Hmm... I don't think that all of the 3GPP references are quite right: - TS 23.811 should I guess be TR 23.811. That ended at release 8.0.0. I quote the last sentence from the TR's conclusions: "The architecture and flows have been transferred to TS 23.204 [5] and this Technical Report will not be updated anymore. For an accurate and up-to-date description of service-level interworking, please refer to TS 23.204 [5]." - Likewise for the other study. Unless things have changed, all xx.8xx docs are studies/reports (TR), not standards (TS). - For the rest of the 3GPP references, they seem about right. (If anyone has any doubts about SIP's capacity for generating gainful employment, please look at the 3GPP specs. Get the 2008-03 status document from and click on the links in that status doc to peel back the many layers of the onion. I did, and it took me a good couple of hours to stop laughing. This explains a lot about SIP/SIPPING/SIMPLE/Bliss/... It also explain why SMPP might be widely implemented, even if the SMPP spec is at risk of disappearing from the 'Net:). all the best, Lawrence From the simple On 5 Apr 2008, at 01:58, Richard Shockey wrote: > draft-yu-enumservice-sms-smpp-00.txt _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Apr 5 19:57:26 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5193A6991; Sat, 5 Apr 2008 19:57: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 625DF3A6991 for ; Sat, 5 Apr 2008 19:57:26 -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 Bl-y9sN-kMUv for ; Sat, 5 Apr 2008 19:57:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D374E3A6828 for ; Sat, 5 Apr 2008 19:57:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,610,1199682000"; d="scan'208";a="4191916" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2008 22:57:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m362vXe3006405; Sat, 5 Apr 2008 22:57:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m362vX3Q016908; Sun, 6 Apr 2008 02:57:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 22:57:33 -0400 Received: from [10.82.216.180] ([10.82.216.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 22:57:33 -0400 Message-ID: <47F83C35.10605@cisco.com> Date: Sat, 05 Apr 2008 22:57:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <138501c8967d$8ef10e20$acd32a60$@us> <02d101c89722$0b1050c0$640fa8c0@cis.neustar.com> In-Reply-To: <02d101c89722$0b1050c0$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 06 Apr 2008 02:57:33.0269 (UTC) FILETIME=[F5F69850:01C89791] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4330; t=1207450653; x=1208314653; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20 |To:=20Brian=20Rosen=20; bh=HadzYVMvQ+RJ/gOCEUqq0SJMcOc1jKkymiQLMa9LQJY=; b=w7FzS9ftmFmK+HzxWeYlma3ECFEDy0RzLIzadLqg0MkbrLGXxRyZCAPnsc wXD65U5MhovKG9P+AxD0wyxReYIeH3M3WXDTyv0GiGULpDLJwwZBIwfM8nlI 1OTOpYT66S; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Ray.Bellis@nominet.org.uk, enum@ietf.org, 'Hadriel Kaplan' Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: > I think we're tending to agree that the data is useful, and disagree on how > you get it. > > I think we're tending to agree that even if you use private ENUM, you need > the data. > > The question is then where to put it. > > I would point out that the SOURCE of the data is the number plan > administrator in a country, which is distinctly different from the operator > of the public enum tree, if there is one. I will admit that I don't fully understand this stuff, so the following might be nonsense... IIUC this may be the responsibility of the number plan administrator of a country in those cases where that isn't delegated. But in some places it is indeed delegated, perhaps all the way down to an end customer. Certainly is sounds like it is that way in Germany. > I'd rather see a mechanism that the number plan administrator could use > directly, and I'd like to avoid the delegation issues of public enum. In those cases where number length can be delegated it is *just* like the delegation issues of public enum. That is why it seems interesting to use the same or an analogous mechanism. If the only variability was at the country level then I would agree with you that this is overkill and the data ought to simply be provisioned. Is would be quite feasible for individual UAs to be provisioned with data for all countries. But not every business in Germany. Paul > It's really just a file. Couldn't we just define an XML data structure for > that file and figure out a way to publish it? > > Brian > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Saturday, April 05, 2008 1:49 AM > To: Ray.Bellis@nominet.org.uk > Cc: enum@ietf.org > Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 > > Howdy, > I don't disagree with the points you guys are making, but I wonder if you're > coming at this from the wrong angle given the relative sensitivities to > ENUM-specific uses of DNS. > > If one of your use-cases or goals is to enable this for public ENUM, I think > one way to look at this is simply as a DNS problem. Alice has asked a DNS > NAPTR query, for foo.bar.com, and its server would like to tell her that > NAPTR record types don't exist for foo.bar.com but may exist for > *.*.foo.bar.com and *.*.*.foo.bar.com. In other words the server wants to > answer differently than not-found, or with additional detail, and could > answer this way for any RR type asked of it for any name. I have absolutely > zero clue if that's going to help or make it worse in the IETF's view, but > it's different. :) (it could easily be worse, fwiw, because it has a > potential to raise a LOT of issues) > > I hesitated saying this, because I fear what this would mean for UNUSED's > chances of getting approved, but another way to look at it is as a specific > type of UNUSED scenario, obviously. Alice has asked a DNS NAPTR query for > 1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all), > so all you're missing is something in the resulting data URN to tell the > client why. (the latest draft is an http URL, but I'm going to try to revert > to a data one that is well-defined, a la pstndata) But at least you could > then simply define an extension ABNF and semantics for the unused-data URN > in a separate draft. It would not break UNUSED, because the unknown > extension abnf in the URN would simply be ignored. > > If your goal is only private ENUM, but you want it publicly documented to > foster interop with vendors for private use (a goal which I can certainly > understand), then nothing stops you from defining it for UNUSED or your > current way as an informational RFC, with clear language regarding > applicability. But I still think it would be good to hash out the best way > for it to be done, so that it's not specific to private use in the UK. > > -hadriel > _______________________________________________ > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 7 02:00:56 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469AB3A6BB6; Mon, 7 Apr 2008 02:00: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 7CA8D3A6C94 for ; Mon, 7 Apr 2008 02:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.267, 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 LMf+dTxzvQBK for ; Mon, 7 Apr 2008 02:00:52 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 544A53A6B73 for ; Mon, 7 Apr 2008 02:00:51 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1JinCX-0004uO-00; Mon, 07 Apr 2008 10:59:41 +0200 Date: Mon, 7 Apr 2008 10:59:41 +0200 From: Otmar Lendl To: Brian Rosen Message-ID: <20080407085941.GA18829@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , 'Paul Kyzivat' , 'Richard Shockey' , enum@ietf.org, "'Clive D.W. Feather'" , 'Duane' References: <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.9i Cc: enum@ietf.org, 'Paul Kyzivat' , "'Clive D.W. Feather'" , 'Duane' , 'Richard Shockey' Subject: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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/04/04 19:04, Brian Rosen wrote: > One thing I don't think we have to do is give the black phone or black phone > connected to TA a BETTER experience than they have now. > > Those of you in countries that allow this kind of "enterprise can define how > long the number is", what is the user experience? You can route as soon as > the prefix is entered. What is the user experience after that? What if > there was a short or a long pause between the prefix and one of the > internally consumed digits? After all, the originating switch doesn't know > how many digits the enterprise uses. The simple answer is: The user does not notice that the PBX on the terminating side is not integrated into the operator's switch. It's all completely transparent and realtime. Overlap dialing is an end-to-end feature: individual digits are passed from originating PBX, via originating carrier, via destiation carrier to the receiving PBX. Here are some D-channel traces to explain this (using Asterisk connected to a Colt ISDN PRI, calling is via Telekom Austria.) Lines starting with < are receiving, the ones with > are sent to the operator. I'm calling extension 300 on +43 1 25397. 1) Direct dialing (incl. extension) < Message type: SETUP (5) < Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '300' ] New call coming in, indicting extension 300. Actually, it is a config option on an ISDN line whether these "Called Number" messages contains just the extension or the national number + extension. > Message type: SETUP ACKNOWLEDGE (13) > Message type: CONNECT (7) "300" is known, thus Asterisk accpects the call. < Message type: CONNECT ACKNOWLEDGE (15) 2) overlap dialing. On the sending side, all digits are passed one by one to the operator, the second I hit the '7' key, I see on the receiving side: < Message type: SETUP (5) There is no "called number" information element in the setup message > Message type: SETUP ACKNOWLEDGE (13) I continue dialing and see < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3' ] then: < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] At this point, the Asterisk knows that the extension is complete and thus sends: > Message type: CONNECT (7) 3) Timeout (receiving side): Here is the case where the receiving side implements a timeout: Overlap-dialing till the 7, then waiting: < Message type: SETUP (5) (no called party IE) > Message type: SETUP ACKNOWLEDGE (13) (some seconds later) > Message type: CONNECT (7) 4) Timeout (sending side) I can't reproduce this right now, but I rememeber that when calling from a POTS phone, the network will issue a "SENDING COMPLETE" IE to the receiving ISDN line after a suitable delay. ------------ I hope this helps a bit. /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 Apr 7 05:56:47 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B426B3A6C5E; Mon, 7 Apr 2008 05:56: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 1F1693A6A90 for ; Mon, 7 Apr 2008 05:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_20=-0.74, 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 9JiTZajeT7da for ; Mon, 7 Apr 2008 05:56:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D40453A6DA8 for ; Mon, 7 Apr 2008 05:56:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jiqu2-0000Yv-D6; Mon, 07 Apr 2008 07:56:50 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" References: <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> <20080407085941.GA18829@nic.at> Date: Mon, 7 Apr 2008 08:56:51 -0400 Message-ID: <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080407085941.GA18829@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciYjbe13l0xXzLHRcKbOEytySknKAAH/uqA 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, 'Paul Kyzivat' , "'Clive D.W. Feather'" , 'Duane' , 'Richard Shockey' Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Right. So, there is indeed a pretty substantial problem to do something sensible for a SIP version of this. The network could complete its processing of the call as soon as it has sufficient digits to route. The originating end however needs to know how many more digits there will be in order to actually send a complete INVITE, and the receiving end can't issue an 200 until it has all the digits. Seems like we have two choices, neither of them good. 1) We build a database which really is delegated out to enterprises, and require that they populate the database if they want to get calls, and have the originating side collect the right number of digits, and send a single INVITE with the correct telephone number 2) Have the originating side send an INVITE when it has at least the prefix number of digits, and then let the receiving end collect DTMF to determine the rest of the digits using early media. To get the right user experience, you can't complete the call until all the required digits are entered. Just another user experience question: Suppose there was a network busy condition. The user is going to get the error tone after they enter the prefix, but before they have completed dialing, right? Brian -----Original Message----- From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl Sent: Monday, April 07, 2008 5:00 AM To: Brian Rosen Cc: 'Paul Kyzivat'; 'Richard Shockey'; enum@ietf.org; 'Clive D.W. Feather'; 'Duane' Subject: Overlap dialing user experience (Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00) On 2008/04/04 19:04, Brian Rosen wrote: > One thing I don't think we have to do is give the black phone or black phone > connected to TA a BETTER experience than they have now. > > Those of you in countries that allow this kind of "enterprise can define how > long the number is", what is the user experience? You can route as soon as > the prefix is entered. What is the user experience after that? What if > there was a short or a long pause between the prefix and one of the > internally consumed digits? After all, the originating switch doesn't know > how many digits the enterprise uses. The simple answer is: The user does not notice that the PBX on the terminating side is not integrated into the operator's switch. It's all completely transparent and realtime. Overlap dialing is an end-to-end feature: individual digits are passed from originating PBX, via originating carrier, via destiation carrier to the receiving PBX. Here are some D-channel traces to explain this (using Asterisk connected to a Colt ISDN PRI, calling is via Telekom Austria.) Lines starting with < are receiving, the ones with > are sent to the operator. I'm calling extension 300 on +43 1 25397. 1) Direct dialing (incl. extension) < Message type: SETUP (5) < Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '300' ] New call coming in, indicting extension 300. Actually, it is a config option on an ISDN line whether these "Called Number" messages contains just the extension or the national number + extension. > Message type: SETUP ACKNOWLEDGE (13) > Message type: CONNECT (7) "300" is known, thus Asterisk accpects the call. < Message type: CONNECT ACKNOWLEDGE (15) 2) overlap dialing. On the sending side, all digits are passed one by one to the operator, the second I hit the '7' key, I see on the receiving side: < Message type: SETUP (5) There is no "called number" information element in the setup message > Message type: SETUP ACKNOWLEDGE (13) I continue dialing and see < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3' ] then: < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] < Message type: INFORMATION (123) < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] At this point, the Asterisk knows that the extension is complete and thus sends: > Message type: CONNECT (7) 3) Timeout (receiving side): Here is the case where the receiving side implements a timeout: Overlap-dialing till the 7, then waiting: < Message type: SETUP (5) (no called party IE) > Message type: SETUP ACKNOWLEDGE (13) (some seconds later) > Message type: CONNECT (7) 4) Timeout (sending side) I can't reproduce this right now, but I rememeber that when calling from a POTS phone, the network will issue a "SENDING COMPLETE" IE to the receiving ISDN line after a suitable delay. ------------ I hope this helps a bit. /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 Apr 7 06:56:19 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C3528C39A; Mon, 7 Apr 2008 06:56: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 BB74E28C38F for ; Mon, 7 Apr 2008 06:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 LEL7eIx0Oel9 for ; Mon, 7 Apr 2008 06:56:14 -0700 (PDT) Received: from smtp1.freeserve.com (smtp1.wanadoo.co.uk [193.252.22.158]) by core3.amsl.com (Postfix) with ESMTP id DB00C28C376 for ; Mon, 7 Apr 2008 06:56:13 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3012.me.freeserve.com (SMTP Server) with ESMTP id C9B031C00086; Mon, 7 Apr 2008 15:56:24 +0200 (CEST) Received: from Codalogic (user-514c0bb0.l1.c5.dsl.pol.co.uk [81.76.11.176]) by mwinf3012.me.freeserve.com (SMTP Server) with SMTP id B5A771C00081; Mon, 7 Apr 2008 15:56:22 +0200 (CEST) X-ME-UUID: 20080407135622744.B5A771C00081@mwinf3012.me.freeserve.com Message-ID: <001401c898b7$299b2650$3b00a8c0@Codalogic> From: "Pete Cordell" To: "Brian Rosen" , "'Otmar Lendl'" References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> Date: Mon, 7 Apr 2008 14:56:16 +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, 'Paul Kyzivat' , "'Clive D.W. Feather'" , 'Duane' , 'Richard Shockey' Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: "Brian Rosen" > Seems like we have two choices, neither of them good. > 1) We build a database which really is delegated out to enterprises, and > require that they populate the database if they want to get calls, and > have > the originating side collect the right number of digits, and send a single > INVITE with the correct telephone number > 2) Have the originating side send an INVITE when it has at least the > prefix > number of digits, and then let the receiving end collect DTMF to determine > the rest of the digits using early media. To get the right user > experience, > you can't complete the call until all the required digits are entered. Another option may be to reject the INVITE with some kind of message (I guess 4xx, but could it be some kind of moved 3xx type thing?) that says insufficient digits and don't try to contact me again until you have n more digits. Pete. -- ============================================= Pete Cordell Codalogic ============================================= _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 7 07:01:32 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397DE3A6E7F; Mon, 7 Apr 2008 07:01: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 73ED43A6EB3 for ; Mon, 7 Apr 2008 07:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 tGxh0WObZ1-E for ; Mon, 7 Apr 2008 07:01:29 -0700 (PDT) Received: from labs.nic.at (nat.labs.nic.at [83.136.33.3]) by core3.amsl.com (Postfix) with ESMTP id 7BF0D3A6EB2 for ; Mon, 7 Apr 2008 07:01:29 -0700 (PDT) Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Jirul-0004x8-00 for ; Mon, 07 Apr 2008 16:01:39 +0200 Date: Mon, 7 Apr 2008 16:01:39 +0200 From: Otmar Lendl To: enum@ietf.org Message-ID: <20080407140139.GA19034@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> <20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.9i Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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/04/07 14:04, Brian Rosen wrote: > > 2) Have the originating side send an INVITE when it has at least the prefix > number of digits, and then let the receiving end collect DTMF to determine > the rest of the digits using early media. To get the right user experience, > you can't complete the call until all the required digits are entered. Asterisk seems to do something similar to this. > Just another user experience question: > Suppose there was a network busy condition. The user is going to get the > error tone after they enter the prefix, but before they have completed > dialing, right? Yes. It doesn't happen much these days, but on a POTS service you used to get the network busy cadence the moment you dial e.g. the area code towards which the network was busy. /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 Apr 7 10:25:41 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1083A68DB; Mon, 7 Apr 2008 10:25: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 76ABA3A6A46 for ; Mon, 7 Apr 2008 02:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 DPtqwu-2+jqz for ; Mon, 7 Apr 2008 02:10:26 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 0A2F028C212 for ; Mon, 7 Apr 2008 02:10:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1207559412; x=1207645812; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=LLEpZH7tf+0Qt62IKu0sV90kEvyd2c3aaxWLcQiacnPGshfJoU5uQnDkiEaL23w/XsbAOGr9iF6ru3 gET6sTdQ== Received: from ([10.31.13.31]) by chihiron1.nc.neustar.com with ESMTP id 5202942.5496206; Mon, 07 Apr 2008 05:09:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 05:09:58 -0400 Message-ID: In-Reply-To: <52FA3718-084E-4630-A7D9-881FE48E0C35@insensate.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-00.txt Thread-Index: AciXe5WIIq1OV20fRR+W7kxM9SdamQA+wqAg References: <0b1901c896b8$38955a00$a9c00e00$@us> <52FA3718-084E-4630-A7D9-881FE48E0C35@insensate.co.uk> From: "Yu, James" To: "Lawrence Conroy" X-Mailman-Approved-At: Mon, 07 Apr 2008 10:25:38 -0700 Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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, Thanks for the comments. Please see the responses below that begin with [YU]. James -----Original Message----- From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Sent: Saturday, April 05, 2008 8:17 PM To: Yu, James; Rich Shockey (Contact) Cc: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-00.txt Hi James, Richard, folks, many thanks for forwarding this. I was a little surprised that James didn't mention it on list. You must have beaten him to it. (i) The formatting is borked on the draft - this makes it hard to read as the text clashes with/runs into the headers. [YU] The problem is caused by the "long" header that makes it seem to be part of the main texts. I'll try to shorten the header to increase the readability. (ii) I AssUMe that the draft is intended to update RFC 4355. It should state that in the header, explain how it updates it (by adding a new sub-type), AND it should refer to RFC 4355 in the normative references. [YU] Yes, it updates RFC 4355. I'll reflect that in the title and add RFC 4355 in the Normative References section. (iii) Whilst we're at it, it IS confusing to have the Enumservice & URI registration intermingled throughout the draft. The CNAM document has a MUCH clearer separation. I hope that by -07 this will be as easy to read :). [YU] I'll try to make it clearer in the next version. (iv) It is NOT clear how SMPP fits with IMS (or doesn't). If it doesn't, then why have refs. to 3GPP IMS specs (notably 24.341 version 7.2.0)? If it does, then I'd strongly recommend referring out to the 3GPP architecture diagrams, and the reference points they specify - it made life easier in getting 4355 through its Loooooong gestation period in the IESG. From experience, you WILL need to explain how these all fit together - and frankly, I think that would be a very useful addition to the next version of the draft. [YU] SMPP has no relationship with IMS. Right now in IMS the IP-SM-GW only supports SS7 and SIP. But because the SMSC/SMS GW products support SMPP and not SIP (at least not now), an operator can advertise via Carrier ENUM that its SMS GW/SMS Router/IP-SM-GW can support SMPP. I'll clarify that IP-SM-GW supports SS7 and SIP in the 3GPP specifications but an operator can make an implementation decision to have IP-SM-GW support SMPP to receive incoming SMS traffic. (iv) Regardless of how widely it may (or may not) be implemented, if you're going to specify a URI scheme, then pointing to the protocol spec would be good: - The SMPP Forum doesn't exist any more. - The SMS Forum (into which it morphed) has also shut down. + However, its web site still has links to the specs. In the case of SMPP, it is at . ? That version appears to be later than the interim version to which the internet draft refers. [YU] I'll use "SMS Forum" and v5.0. (v) Hmm... I don't think that all of the 3GPP references are quite right: - TS 23.811 should I guess be TR 23.811. That ended at release 8.0.0. I quote the last sentence from the TR's conclusions: "The architecture and flows have been transferred to TS 23.204 [5] and this Technical Report will not be updated anymore. For an accurate and up-to-date description of service-level interworking, please refer to TS 23.204 [5]." - Likewise for the other study. Unless things have changed, all xx.8xx docs are studies/reports (TR), not standards (TS). - For the rest of the 3GPP references, they seem about right. (If anyone has any doubts about SIP's capacity for generating gainful employment, please look at the 3GPP specs. Get the 2008-03 status document from and click on the links in that status doc to peel back the many layers of the onion. I did, and it took me a good couple of hours to stop laughing. This explains a lot about SIP/SIPPING/SIMPLE/Bliss/... It also explain why SMPP might be widely implemented, even if the SMPP spec is at risk of disappearing from the 'Net:). [YU] It should be TR 23.811 v8.0.0 instead of TS 23.811 v1.2.1. Since TS 23.204 would include updated info, I'll also include TS 23.204 in the Informative References section. 3GPP first specified the IP-SM-GW to support SMS over IP. When addressing service-level interworking (SM-IM interworking), it was assumed/decided that IP-SM-GW would also be the entity that supports service-level interworking. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 7 11:01:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7293A6EB9; Mon, 7 Apr 2008 11:01: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 A9A803A6EB9 for ; Mon, 7 Apr 2008 11:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.059 X-Spam-Level: X-Spam-Status: No, score=-5.059 tagged_above=-999 required=5 tests=[AWL=1.540, 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 5JbO-jPOPYtw for ; Mon, 7 Apr 2008 11:01:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 895E53A6D5E for ; Mon, 7 Apr 2008 11:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,618,1199682000"; d="scan'208";a="4313082" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2008 14:02:01 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m37I21uk011887; Mon, 7 Apr 2008 14:02:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m37I21VZ015562; Mon, 7 Apr 2008 18:02:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 14:02:00 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 14:02:00 -0400 Message-ID: <47FA61B2.90002@cisco.com> Date: Mon, 07 Apr 2008 14:02:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us> <47F65822.5030205@cisco.com> <01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com> <20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> In-Reply-To: <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 07 Apr 2008 18:02:00.0633 (UTC) FILETIME=[7A3EF290:01C898D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6035; t=1207591321; x=1208455321; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Overlap=20dialing=20user=20experience=2 0(Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft=0A=20-=20dr aft-bellis-enum-send-n-00) |Sender:=20 |To:=20Brian=20Rosen=20; bh=k2KF2iZOs5JxkkikQTwBevn1PN2UJuxEYxThnlN8+VU=; b=NhhPMyTuMweMIb9ddfEgrfTh0LCBV1rYaof5/YNDxYvbA5EZg1U1y5yE6I Y24/B2Z3iX/AWsmL8t8inenrBnhAxSg2KURHk3IBCm56XMxPq4xJDbz7dQCN 4HMLBUjkhS; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: enum@ietf.org, "'Clive D.W. Feather'" , 'Otmar Lendl' , 'Duane' , 'Richard Shockey' Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 There is a bit of a problem for sure. While there is theoretically a "overlap dialing" solution in RFC3578, but its my impression that this is rarely implemented, and that there are technical problems in doing so. Brian Rosen wrote: > Right. > > So, there is indeed a pretty substantial problem to do something sensible > for a SIP version of this. The network could complete its processing of the > call as soon as it has sufficient digits to route. The originating end > however needs to know how many more digits there will be in order to > actually send a complete INVITE, and the receiving end can't issue an 200 > until it has all the digits. > > Seems like we have two choices, neither of them good. > 1) We build a database which really is delegated out to enterprises, and > require that they populate the database if they want to get calls, and have > the originating side collect the right number of digits, and send a single > INVITE with the correct telephone number This would certainly be good from the caller's perspective. Whether it is feasible is TBD. Note that presumably we would need this populated even for enterprises that are connected to the PSTN and have no sip usage of their own, in order that sip-based callers can call them via gateways. IMO a solution needs to work when either caller or callee or both are sip, and in the latter case whether the entire path is sip or there a pstn hop in the middle. And from what I have picked up from marketing types, determining end of dialing by timers is *not* an acceptable user experience. Paul > 2) Have the originating side send an INVITE when it has at least the prefix > number of digits, and then let the receiving end collect DTMF to determine > the rest of the digits using early media. To get the right user experience, > you can't complete the call until all the required digits are entered. > > Just another user experience question: > Suppose there was a network busy condition. The user is going to get the > error tone after they enter the prefix, but before they have completed > dialing, right? > > Brian > > -----Original Message----- > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl > Sent: Monday, April 07, 2008 5:00 AM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'Richard Shockey'; enum@ietf.org; 'Clive D.W. Feather'; > 'Duane' > Subject: Overlap dialing user experience (Re: [Enum] I-D Action: New draft - > draft-bellis-enum-send-n-00) > > On 2008/04/04 19:04, Brian Rosen wrote: >> One thing I don't think we have to do is give the black phone or black > phone >> connected to TA a BETTER experience than they have now. >> >> Those of you in countries that allow this kind of "enterprise can define > how >> long the number is", what is the user experience? You can route as soon > as >> the prefix is entered. What is the user experience after that? What if >> there was a short or a long pause between the prefix and one of the >> internally consumed digits? After all, the originating switch doesn't > know >> how many digits the enterprise uses. > > The simple answer is: The user does not notice that the PBX on the > terminating side is not integrated into the operator's switch. It's all > completely transparent and realtime. Overlap dialing is an end-to-end > feature: individual digits are passed from originating PBX, via > originating carrier, via destiation carrier to the receiving PBX. > > Here are some D-channel traces to explain this (using Asterisk > connected to a Colt ISDN PRI, calling is via Telekom Austria.) > > Lines starting with < are receiving, the ones with > are sent to the > operator. > > I'm calling extension 300 on +43 1 25397. > > 1) Direct dialing (incl. extension) > > < Message type: SETUP (5) > < Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: > ISDN/Telephony Numbering Plan (E.164/E.163) (1) '300' ] > > New call coming in, indicting extension 300. Actually, it is a config > option on an ISDN line whether these "Called Number" messages contains > just the extension or the national number + extension. > >> Message type: SETUP ACKNOWLEDGE (13) >> Message type: CONNECT (7) > > "300" is known, thus Asterisk accpects the call. > > < Message type: CONNECT ACKNOWLEDGE (15) > > 2) overlap dialing. > > On the sending side, all digits are passed one by one to the operator, > the second I hit the '7' key, I see on the receiving side: > > < Message type: SETUP (5) > There is no "called number" information element in the setup message > >> Message type: SETUP ACKNOWLEDGE (13) > > I continue dialing and see > > < Message type: INFORMATION (123) > < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: > ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3' ] > > then: > > < Message type: INFORMATION (123) > < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: > ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] > > < Message type: INFORMATION (123) > < Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: > ISDN/Telephony Numbering Plan (E.164/E.163) (1) '0' ] > > At this point, the Asterisk knows that the extension is complete > and thus sends: > >> Message type: CONNECT (7) > > 3) Timeout (receiving side): > > Here is the case where the receiving side implements a timeout: > > Overlap-dialing till the 7, then waiting: > > < Message type: SETUP (5) (no called party IE) >> Message type: SETUP ACKNOWLEDGE (13) > > (some seconds later) > >> Message type: CONNECT (7) > > 4) Timeout (sending side) > > I can't reproduce this right now, but I rememeber that when calling > from a POTS phone, the network will issue a "SENDING COMPLETE" IE > to the receiving ISDN line after a suitable delay. > > ------------ > > I hope this helps a bit. > > /ol _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 8 15:23:43 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1117C3A6E0B; Tue, 8 Apr 2008 15:23: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 5A39A3A6C06 for ; Tue, 8 Apr 2008 15:23:42 -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 kwuDbFo3vOel for ; Tue, 8 Apr 2008 15:23:41 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id B5B4D3A6C8D for ; Tue, 8 Apr 2008 15:23:40 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA02.westchester.pa.mail.comcast.net with comcast id B8GY1Z0010QuhwU520Em00; Tue, 08 Apr 2008 22:22:45 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA02.westchester.pa.mail.comcast.net with comcast id BAPu1Z00A02AVH03N00000; Tue, 08 Apr 2008 22:23:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=f1B5su781V0A:10 a=S9thlWvj4BEA:10 a=X69QBQ93YS3fCPFwp5cA:9 a=ztVzxyQUJ95EAxFuwIo6vV02EBwA:4 a=aEpGgNBHC-0A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m38MNsEA008472 for ; Tue, 8 Apr 2008 18:23:54 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m38MNsD1008468; Tue, 8 Apr 2008 18:23:54 -0400 Date: Tue, 8 Apr 2008 18:23:54 -0400 Message-Id: <200804082223.m38MNsD1008468@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <001401c898b7$299b2650$3b00a8c0@Codalogic> (peteietf@codalogic.com) References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> <001401c898b7$299b2650$3b00a8c0@Codalogic> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 From: "Pete Cordell" Another option may be to reject the INVITE with some kind of message (I guess 4xx, but could it be some kind of moved 3xx type thing?) that says insufficient digits and don't try to contact me again until you have n more digits. RFC 3261, section 21.4.22: 484 Address Incomplete The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase. This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response. If we want to send partial-dial-string queries into the network, as in Otmar's example, we might as well use INVITE and 484 responses as they are already defined. The refinement would be to be able to provide information as to the minimum number of additional digits needed in the 484 response. Dale _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 8 18:53:31 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A2A3A6895; Tue, 8 Apr 2008 18:53: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 05D863A6895 for ; Tue, 8 Apr 2008 18:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 FRjpbO0ajU-y for ; Tue, 8 Apr 2008 18:53: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 5DFAF3A67F7 for ; Tue, 8 Apr 2008 18:53:30 -0700 (PDT) Received: from [192.168.100.101] (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 D578A5AC37E for ; Wed, 9 Apr 2008 11:53:43 +1000 (EST) Message-ID: <47FC2194.9090807@e164.org> Date: Wed, 09 Apr 2008 11:53:24 +1000 From: Duane User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: enum@ietf.org References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> <001401c898b7$299b2650$3b00a8c0@Codalogic> <200804082223.m38MNsD1008468@dragon.ariadne.com> In-Reply-To: <200804082223.m38MNsD1008468@dragon.ariadne.com> X-Enigmail-Version: 0.95.0 Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Dale.Worley@comcast.net wrote: > From: "Pete Cordell" > > Another option may be to reject the INVITE with some kind of message (I > guess 4xx, but could it be some kind of moved 3xx type thing?) that says > insufficient digits and don't try to contact me again until you have n more > digits. What about non-VoIP applications that failed to find a URI and want to check if the length was valid? -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 8 20:01:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4967F3A6AFD; Tue, 8 Apr 2008 20:01: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 8B0363A6AFD for ; Tue, 8 Apr 2008 20:01:26 -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 9aYduheNxeFo for ; Tue, 8 Apr 2008 20:01:25 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id A5F7D3A6836 for ; Tue, 8 Apr 2008 20:01:25 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id BCDv1Z0060mv7h05A06t00; Wed, 09 Apr 2008 03:00:40 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA11.westchester.pa.mail.comcast.net with comcast id BF1h1Z00502AVH03X00000; Wed, 09 Apr 2008 03:01:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=VXBj00zGX6UA:10 a=LbEHpfud3i4A:10 a=FgwyS9yqS2LGDnMIt9kA:9 a=EJhyYTb4ThCBfq_PF5FxueNfLFcA:4 a=-zy3ex45pM4A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3931fEA028870 for ; Tue, 8 Apr 2008 23:01:41 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3931eBe028866; Tue, 8 Apr 2008 23:01:40 -0400 Date: Tue, 8 Apr 2008 23:01:40 -0400 Message-Id: <200804090301.m3931eBe028866@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> (br@brianrosen.net) References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 From: "Brian Rosen" I think this is the crux of the matter. We do, actually, need to know the length of a TN in order to support overlapped dialing, Do we actually need to support overlapped dialing? My belief is that (in the US) international calls (outside the +1 area) terminate dialing with a time-out, or by the user pushing '#'. At the moment, my desk phone is a SIP phone, and it's got a "Send" softkey to terminate dialing. Our customers have made some noises that they'd like our PBX's configuration system to work out the dialplan regexp for their phones, but as a feature request, it is remarkably far down the list. So from where I stand, the demand for overlapped dialing seems to be rather weak. Dale _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 8 20:25:32 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C8F3A6EE7; Tue, 8 Apr 2008 20:25: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 59F363A6EE3 for ; Tue, 8 Apr 2008 20:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 ghh+C++CAB1v for ; Tue, 8 Apr 2008 20:25:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F1593A6EE4 for ; Tue, 8 Apr 2008 20:25:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Apr 2008 23:25:13 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 23:25:03 -0400 From: Hadriel Kaplan To: "Dale.Worley@comcast.net" , "enum@ietf.org" Date: Tue, 8 Apr 2008 23:22:18 -0400 Thread-Topic: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 Thread-Index: AciZ7fvo4gvzDch2QG+oNJrYEdy6tAAACQ5w Message-ID: References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <200804090301.m3931eBe028866@dragon.ariadne.com> In-Reply-To: <200804090301.m3931eBe028866@dragon.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > Dale.Worley@comcast.net > > Do we actually need to support overlapped dialing? We've seen it more lately, where they sometimes send multiple SIP INVITEs as more buttons are pushed. It's rather ugly so far. > My belief is that (in the US) international calls (outside the +1 > area) terminate dialing with a time-out, or by the user pushing '#'. > At the moment, my desk phone is a SIP phone, and it's got a "Send" > softkey to terminate dialing. Sure, people have been getting more mobile-phone-trained. :) But lots and lots of SIP is generated by analog/POTS gateways for homes/SMBs, where I think they want a POTS-like black-phone experience. But YMMV. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 8 20:26:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8363A68BB; Tue, 8 Apr 2008 20:26: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 F3AB23A68BB for ; Tue, 8 Apr 2008 20:26:15 -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] 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 KACw5x9M5YIu for ; Tue, 8 Apr 2008 20:26:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DDC253A6856 for ; Tue, 8 Apr 2008 20:26:14 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 8 Apr 2008 23:26:04 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 23:26:04 -0400 From: Hadriel Kaplan To: "Dale.Worley@comcast.net" , "enum@ietf.org" Date: Tue, 8 Apr 2008 23:23:26 -0400 Thread-Topic: [Enum] Overlap dialing user experience (Re: I-D Action: Newdraft - draft-bellis-enum-send-n-00) Thread-Index: AciZxzTdFqXL3hr/RNiItqoszQVYawAKbhOg Message-ID: References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com> <122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at> <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> <001401c898b7$299b2650$3b00a8c0@Codalogic> <200804082223.m38MNsD1008468@dragon.ariadne.com> In-Reply-To: <200804082223.m38MNsD1008468@dragon.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Even if we should send a 484 back, how do we know to send that vs. a 480/604/whatever based on ENUM DNS not-found/unused responses, or even just alternate route it to the PSTN? -hadriel > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Dale.Worley@comcast.net > Sent: Tuesday, April 08, 2008 6:24 PM > To: enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: > Newdraft - draft-bellis-enum-send-n-00) > > From: "Pete Cordell" > > Another option may be to reject the INVITE with some kind of message (I > guess 4xx, but could it be some kind of moved 3xx type thing?) that > says > insufficient digits and don't try to contact me again until you have n > more > digits. > > RFC 3261, section 21.4.22: 484 Address Incomplete > > The server received a request with a Request-URI that was incomplete. > Additional information SHOULD be provided in the reason phrase. > > This status code allows overlapped dialing. With overlapped > dialing, the client does not know the length of the dialing > string. It sends strings of increasing lengths, prompting the > user for more input, until it no longer receives a 484 (Address > Incomplete) status response. > > If we want to send partial-dial-string queries into the network, as > in Otmar's example, we might as well use INVITE and 484 responses as > they are already defined. The refinement would be to be able to > provide information as to the minimum number of additional digits > needed in the 484 response. > > Dale > _______________________________________________ > 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 Apr 8 21:18:38 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EFC3A6B49; Tue, 8 Apr 2008 21:18: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 C38873A6B49 for ; Tue, 8 Apr 2008 21:18:37 -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 HPTmOCtm9sOt for ; Tue, 8 Apr 2008 21:18:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BC3813A6B0F for ; Tue, 8 Apr 2008 21:18:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,626,1199692800"; d="scan'208";a="20625710" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2008 21:18:54 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m394Isds008008; Tue, 8 Apr 2008 21:18:54 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m394Ir51018234; Wed, 9 Apr 2008 04:18:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 00:18:53 -0400 Received: from [10.86.248.141] ([10.86.248.141]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 00:18:53 -0400 Message-ID: <47FC43C6.8060800@cisco.com> Date: Wed, 09 Apr 2008 00:19:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <34DA635B184A644DA4588E260EC0A25A12673BD4@ACCLUST02EVS1.ugd.att.com><20080402210355.GA71089@finch-staff-1.thus.net><47F40BBF.1050308@e164.org> <47F41276.30404@cisco.com><20080404094955.GM35978@finch-staff-1.thus.net> <47F62F13.4000004@cisco.com> <016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com> <200804090301.m3931eBe028866@dragon.ariadne.com> In-Reply-To: <200804090301.m3931eBe028866@dragon.ariadne.com> X-OriginalArrivalTime: 09 Apr 2008 04:18:53.0404 (UTC) FILETIME=[D1FD59C0:01C899F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1290; t=1207714734; x=1208578734; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20I-D=20Action=3A=20New=20draft= 20-=20draft-bellis-enum-send-n-00 |Sender:=20; bh=a81acws7XoFc4/6yHs/PmWTV0RvXR0Z5QBUFLTFHV5g=; b=E/Gm7xv6UwwVDWV4/bPYW4gZz88Hwa511zeSdJ/PFEabJx53m9FCdduj3g X248HLpZYGuAlTZVRDOtjiTpsL4UEOFxFxx+e2qCnz3Uvq/TwykvZR6IE+Eu YJtMKfnxng; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: enum@ietf.org Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Dale, I have marketing people telling me they need solutions for dialing variable length numbers without either a send key or a timeout, in order to give competitive user experience. This is coming up in those countries where variable length numbers are common, not in the US. Paul Dale.Worley@comcast.net wrote: > From: "Brian Rosen" > > I think this is the crux of the matter. > > We do, actually, need to know the length of a TN in order to support > overlapped dialing, > > Do we actually need to support overlapped dialing? > > My belief is that (in the US) international calls (outside the +1 > area) terminate dialing with a time-out, or by the user pushing '#'. > > At the moment, my desk phone is a SIP phone, and it's got a "Send" > softkey to terminate dialing. Our customers have made some noises > that they'd like our PBX's configuration system to work out the > dialplan regexp for their phones, but as a feature request, it is > remarkably far down the list. > > So from where I stand, the demand for overlapped dialing seems to be > rather weak. > > Dale > _______________________________________________ > 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 Wed Apr 9 00:43:50 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80273A6B41; Wed, 9 Apr 2008 00:43: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 9FE493A6B2E for ; Wed, 9 Apr 2008 00:43: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=[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 0TxqP8qZ3ktJ for ; Wed, 9 Apr 2008 00:43:48 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 4234B3A6970 for ; Wed, 9 Apr 2008 00:43:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,627,1199664000"; d="scan'208";a="244953" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 09 Apr 2008 08:44:04 +0100 In-Reply-To: <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Jay Daley Date: Wed, 9 Apr 2008 08:44:03 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/04/2008 08:44:03 AM, Serialize complete at 09/04/2008 08:44:03 AM Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > So, there is indeed a pretty substantial problem to do something sensible > for a SIP version of this. The network could complete its processing of the > call as soon as it has sufficient digits to route. The originating end > however needs to know how many more digits there will be in order to > actually send a complete INVITE, and the receiving end can't issue an 200 > until it has all the digits. You appear to have narrowed the case to solely the German/Austrian example where there is a nationally known prefix and the rest of the digits are variable. This draft is not solely about that but primarily for those countries where the prefix length is different for different prefixes (if you see what I mean!). > 2) Have the originating side send an INVITE when it has at least the prefix > number of digits, and then let the receiving end collect DTMF to determine > the rest of the digits using early media. To get the right user experience, > you can't complete the call until all the required digits are entered. Assuming you try to apply this to that stated use case of this draft (as explained above) then this only works where the SIP URI can be determined from insufficient digits. This is highly unlikely to be the case in user ENUM since each provisioned user number will have chosen their own SIP termination. In infrastructure ENUM it might be possible when a carrier has not lost any numbers from its block allocation to number porting, but those cases will be rare. This draft addresses the issue of determining where to send the INVITE to, so trying to solve this by the way the INVITE process works is contradictory. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 01:24:18 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6643A694D; Wed, 9 Apr 2008 01:24: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 251363A68D3 for ; Wed, 9 Apr 2008 01:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Wv5ZTThsH02M for ; Wed, 9 Apr 2008 01:24:17 -0700 (PDT) Received: from smtp1.freeserve.com (smtp1.wanadoo.co.uk [193.252.22.158]) by core3.amsl.com (Postfix) with ESMTP id 2971B3A6AD4 for ; Wed, 9 Apr 2008 01:24:16 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3008.me.freeserve.com (SMTP Server) with ESMTP id 41BF81C00086; Wed, 9 Apr 2008 10:24:32 +0200 (CEST) Received: from Codalogic (user-514c0bb0.l1.c5.dsl.pol.co.uk [81.76.11.176]) by mwinf3008.me.freeserve.com (SMTP Server) with SMTP id B7AAE1C00085; Wed, 9 Apr 2008 10:24:29 +0200 (CEST) X-ME-UUID: 20080409082429752.B7AAE1C00085@mwinf3008.me.freeserve.com Message-ID: <003801c89a1b$20d67820$3b00a8c0@Codalogic> From: "Pete Cordell" To: "Hadriel Kaplan" , , References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com><122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at><04d601c898ae$dae03f80$640fa8c0@cis.neustar.com><001401c898b7$299b2650$3b00a8c0@Codalogic><200804082223.m38MNsD1008468@dragon.ariadne.com> Date: Wed, 9 Apr 2008 09:24:19 +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 Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: "Hadriel Kaplan" To: ; Sent: Wednesday, April 09, 2008 4:23 AM Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00) > > Even if we should send a 484 back, how do we know to send that vs. a > 480/604/whatever based on > ENUM DNS not-found/unused responses, or even just alternate route it to > the PSTN? My thinking was that the UA would do an ENUM query for a number, and get back some sort of successful, go here response. The UA would then send an INVITE and maybe get a 484 then. So in the case of this German hotel, the ENUM query would be based on the E.164 data that the number provider has, and would resolve to the hotel SIP proxy. The initial INVITE would be sent and the hotel's SIP proxy would then be able to say, "484: well actually we need a few more numbers". I must confess that I'm not following all the issues about the impact of wildcards and relative vs. fixed length n's in the send-n proposal, but I could see something like send-n in ENUM and 484 in SIP complementing each other rather than competing. HTH, Pete. -- ============================================= Pete Cordell Codalogic ============================================= >> -----Original Message----- >> From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of >> Dale.Worley@comcast.net >> Sent: Tuesday, April 08, 2008 6:24 PM >> To: enum@ietf.org >> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: >> Newdraft - draft-bellis-enum-send-n-00) >> >> From: "Pete Cordell" >> >> Another option may be to reject the INVITE with some kind of message >> (I >> guess 4xx, but could it be some kind of moved 3xx type thing?) that >> says >> insufficient digits and don't try to contact me again until you have n >> more >> digits. >> >> RFC 3261, section 21.4.22: 484 Address Incomplete >> >> The server received a request with a Request-URI that was incomplete. >> Additional information SHOULD be provided in the reason phrase. >> >> This status code allows overlapped dialing. With overlapped >> dialing, the client does not know the length of the dialing >> string. It sends strings of increasing lengths, prompting the >> user for more input, until it no longer receives a 484 (Address >> Incomplete) status response. >> >> If we want to send partial-dial-string queries into the network, as >> in Otmar's example, we might as well use INVITE and 484 responses as >> they are already defined. The refinement would be to be able to >> provide information as to the minimum number of additional digits >> needed in the 484 response. >> >> Dale >> _______________________________________________ >> 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 > _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 06:16:34 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953D328C49B; Wed, 9 Apr 2008 06:16: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 3FDA428C4B1 for ; Wed, 9 Apr 2008 06:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.746, 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 Dx3BsCvJG3ns for ; Wed, 9 Apr 2008 06:16:25 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D246328C479 for ; Wed, 9 Apr 2008 06:16:25 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjaAK-0005BW-8G; Wed, 09 Apr 2008 08:16:40 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <04d601c898ae$dae03f80$640fa8c0@cis.neustar.com> Date: Wed, 9 Apr 2008 09:16:38 -0400 Message-ID: <078001c89a43$f482fa90$640fa8c0@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: AciaFXzeSMWH1/DhTYOvqGYIK1y8HQAK738Q 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] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 think the mechanism needed by carriers to route calls is a heck of a lot easier to solve then a mechanism needed by a phone to dial a hotel that decided on its own how long it's numbers are. If you want to generalize to "needed by originators" instead of carriers, it doesn't change the problem. The number of digits needed to route to the termination domain is determined by a block assignment by a number administrator. There is one per country of them. Creating a system where we define a way for them to communicate block assignments seems to be a pretty tractable problem. The number of digits needed to complete a call where the termination domain chooses the number length is a bigger problem, with a much more difficult delegation problem. Essentially it requires something on the order of user enum, with small groups of numbers delegated to the termination domain. User enum has not been an unqualified success. We can manage delegation down to small units (I have 3 domains I manage, how about you?, but it's messy, and takes a lot of work, and costs $10 a year in the marketplace. In fact it probably works where user enum doesn't because it is a marketplace, and there is choice of TLDs. In this case, we really are down to managing a single root, which implies monopolies, and we get all the problems we have with user enum. So, I'd rather come up with a solution to the route-to-the-domain problem, and come up with a sip solution for the route-to-the-phone problem. Brian -----Original Message----- From: Jay Daley [mailto:jay@nominet.org.uk] Sent: Wednesday, April 09, 2008 3:44 AM To: Brian Rosen Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) Brian > So, there is indeed a pretty substantial problem to do something sensible > for a SIP version of this. The network could complete its processing of the > call as soon as it has sufficient digits to route. The originating end > however needs to know how many more digits there will be in order to > actually send a complete INVITE, and the receiving end can't issue an 200 > until it has all the digits. You appear to have narrowed the case to solely the German/Austrian example where there is a nationally known prefix and the rest of the digits are variable. This draft is not solely about that but primarily for those countries where the prefix length is different for different prefixes (if you see what I mean!). > 2) Have the originating side send an INVITE when it has at least the prefix > number of digits, and then let the receiving end collect DTMF to determine > the rest of the digits using early media. To get the right user experience, > you can't complete the call until all the required digits are entered. Assuming you try to apply this to that stated use case of this draft (as explained above) then this only works where the SIP URI can be determined from insufficient digits. This is highly unlikely to be the case in user ENUM since each provisioned user number will have chosen their own SIP termination. In infrastructure ENUM it might be possible when a carrier has not lost any numbers from its block allocation to number porting, but those cases will be rare. This draft addresses the issue of determining where to send the INVITE to, so trying to solve this by the way the INVITE process works is contradictory. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 07:26:51 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4EA3A6F09; Wed, 9 Apr 2008 07:26: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 B41C53A6AF9 for ; Wed, 9 Apr 2008 07:26:48 -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 AdUUTONj4Doh for ; Wed, 9 Apr 2008 07:26:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CE95028C17F for ; Wed, 9 Apr 2008 07:25:01 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 9 Apr 2008 10:24:51 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 9 Apr 2008 10:24:51 -0400 From: Hadriel Kaplan To: Pete Cordell , "Dale.Worley@comcast.net" , "enum@ietf.org" Date: Wed, 9 Apr 2008 10:22:14 -0400 Thread-Topic: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00) Thread-Index: AciaGxPTpAoDKZY5Smy5aTQbw99+6AAMOTrQ Message-ID: References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com><122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at><04d601c898ae$dae03f80$640fa8c0@cis.neustar.com><001401c898b7$299b2650$3b00a8c0@Codalogic><200804082223.m38MNsD1008468@dragon.ariadne.com> <003801c89a1b$20d67820$3b00a8c0@Codalogic> In-Reply-To: <003801c89a1b$20d67820$3b00a8c0@Codalogic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: Pete Cordell [mailto:peteietf@codalogic.com] > > ----- Original Message ----- > From: "Hadriel Kaplan" > > > Even if we should send a 484 back, how do we know to send that vs. a > > 480/604/whatever based on > > ENUM DNS not-found/unused responses, or even just alternate route it to > > the PSTN? > > My thinking was that the UA would do an ENUM query for a number, and get > back some sort of successful, go here response. The UA would then send an > INVITE and maybe get a 484 then. That's certainly one way to go. I think it's pretty ugly, because it means sending SIP Invites all over the place when they didn't need to, and it means having SIP proxies available for every partial number, but it's one way to go. I mean certainly nothing precludes that model for people/hotels that want it, even if we do decide some other way of handling this issue in general. > So in the case of this German hotel, the ENUM query would be based on the > E.164 data that the number provider has, and would resolve to the hotel > SIP > proxy. The initial INVITE would be sent and the hotel's SIP proxy would > then be able to say, "484: well actually we need a few more numbers". > I must confess that I'm not following all the issues about the impact of > wildcards and relative vs. fixed length n's in the send-n proposal, but I > could see something like send-n in ENUM and 484 in SIP complementing each > other rather than competing. Oh no I didn't mean they were competing - I meant the issue at hand is, imo, how the UAC or proxy doing the ENUM query can know to send back a 484 vs. another failure response (with/without whatever additional data it needs). -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 08:33:42 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D37C28C3CB; Wed, 9 Apr 2008 08:33: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 BCC843A699F for ; Wed, 9 Apr 2008 08:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Jy++kWOMzorc for ; Wed, 9 Apr 2008 08:33:40 -0700 (PDT) Received: from smtp2.freeserve.com (smtp2.wanadoo.co.uk [193.252.22.157]) by core3.amsl.com (Postfix) with ESMTP id 8A97B28C416 for ; Wed, 9 Apr 2008 08:33:40 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3101.me.freeserve.com (SMTP Server) with ESMTP id 37E7C7000095; Wed, 9 Apr 2008 17:33:56 +0200 (CEST) Received: from Codalogic (user-514c0bb0.l1.c5.dsl.pol.co.uk [81.76.11.176]) by mwinf3101.me.freeserve.com (SMTP Server) with SMTP id 256337000084; Wed, 9 Apr 2008 17:33:53 +0200 (CEST) X-ME-UUID: 20080409153353153.256337000084@mwinf3101.me.freeserve.com Message-ID: <001d01c89a57$1d1e0cc0$3b00a8c0@Codalogic> From: "Pete Cordell" To: "Hadriel Kaplan" , , References: <47F62F13.4000004@cisco.com><016601c8965e$9e0d8ec0$640fa8c0@cis.neustar.com><47F63D66.2090909@cisco.com><122101c8966b$f7e360c0$e7aa2240$@us><47F65822.5030205@cisco.com><01aa01c89679$44ee0d40$640fa8c0@cis.neustar.com><20080407085941.GA18829@nic.at><04d601c898ae$dae03f80$640fa8c0@cis.neustar.com><001401c898b7$299b2650$3b00a8c0@Codalogic><200804082223.m38MNsD1008468@dragon.ariadne.com><003801c89a1b$20d67820$3b00a8c0@Codalogic> Date: Wed, 9 Apr 2008 16:33:47 +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 Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: "Hadriel Kaplan" <> >> -----Original Message----- >> From: Pete Cordell [mailto:peteietf@codalogic.com] >> >> ----- Original Message ----- >> From: "Hadriel Kaplan" >> >> > Even if we should send a 484 back, how do we know to send that vs. a >> > 480/604/whatever based on >> > ENUM DNS not-found/unused responses, or even just alternate route it to >> > the PSTN? >> >> My thinking was that the UA would do an ENUM query for a number, and get >> back some sort of successful, go here response. The UA would then send >> an >> INVITE and maybe get a 484 then. > > That's certainly one way to go. I think it's pretty ugly, because it > means sending > SIP Invites all over the place when they didn't need to, and it means > having SIP > proxies available for every partial number, but it's one way to go. I > mean certainly > nothing precludes that model for people/hotels that want it, even if we do > decide > some other way of handling this issue in general. I was envisioning ENUM would get you to the hotel. The UAC would then send an INVITE to the hotel, and its proxy would return 484, I need 4 more digits (or maybe the minumum digit length is 20 or whatever it works out to be). Then the UAC sends a new invite with the extra collected digits. Admittedly the x more digits thing is not in place, but it doesn't seem too difficult to come up with a header that could do that. To me that sounds a lot better than administering some mega database, or sending an initial INVITE to the hotel and then sending extra DTMF (would that be INFO / RTP or whatever etc.?) >> So in the case of this German hotel, the ENUM query would be based on the >> E.164 data that the number provider has, and would resolve to the hotel >> SIP >> proxy. The initial INVITE would be sent and the hotel's SIP proxy would >> then be able to say, "484: well actually we need a few more numbers". >> I must confess that I'm not following all the issues about the impact of >> wildcards and relative vs. fixed length n's in the send-n proposal, but I >> could see something like send-n in ENUM and 484 in SIP complementing each >> other rather than competing. > > Oh no I didn't mean they were competing - I meant the issue at hand is, > imo, how > the UAC or proxy doing the ENUM query can know to send back a 484 vs. > another failure response (with/without whatever additional data it needs). Maybe I'm missing something, but the UAC keeps banging away at ENUM until it gets a 'go here' reply. It then does a SIP INVITE and works from there (unless it gets a tel: re-direct, in which case it's back to ENUM I guess, but hopefully that won't happen!) On reflection, maybe the thing I'm missing is I don't think ENUM has the ability to return a URI that a UAC, after receiving a 484, would be able to figure out how to add, say, 4 more digits to. > > -hadriel > _______________________________________________ > 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 c.neelan@northamericanmediation.com Wed Apr 9 13:21: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 E4A5228C2DF; Wed, 9 Apr 2008 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.242 X-Spam-Level: X-Spam-Status: No, score=-11.242 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, 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, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, 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, RDNS_DYNAMIC=0.1, 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 NmLRKwDVy63e; Wed, 9 Apr 2008 13:21:44 -0700 (PDT) Received: from 190-49-154-218.speedy.com.ar (unknown [190.49.154.218]) by core3.amsl.com (Postfix) with SMTP id 91F2F28C0F6; Wed, 9 Apr 2008 13:21:34 -0700 (PDT) X-Originating-IP: 105.156.107.178 by smtp.190.49.154.218; Wed, 09 Apr 2008 16:22:00 -0500 Message-ID: From: "Patrice Arellano" Reply-To: "Patrice Arellano" To: edu-team-bounces@ietf.org Subject: The safest and most secure Online casino in the world....... Date: Wed, 09 Apr 2008 16:22:00 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://luxgamingnetwork.com/ TO DOWNLOAD NOW! From enum-bounces@ietf.org Wed Apr 9 14:25:57 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D77B28C0F6; Wed, 9 Apr 2008 14:25: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 C3B123A6CD7 for ; Wed, 9 Apr 2008 14:25:55 -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 7RoClfZ42cPT for ; Wed, 9 Apr 2008 14:25:55 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 4DC4D28C19F for ; Wed, 9 Apr 2008 14:25:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,631,1199664000"; d="scan'208";a="222657" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 09 Apr 2008 22:25:26 +0100 In-Reply-To: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Jay Daley Date: Wed, 9 Apr 2008 22:25:25 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/04/2008 10:25:25 PM, Serialize complete at 09/04/2008 10:25:25 PM Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 think the mechanism needed by carriers to route calls is a heck of a lot > easier to solve then a mechanism needed by a phone to dial a hotel that > decided on its own how long it's numbers are. > > If you want to generalize to "needed by originators" instead of carriers, it > doesn't change the problem. > > The number of digits needed to route to the termination domain is determined > by a block assignment by a number administrator. There is one per country > of them. Creating a system where we define a way for them to communicate > block assignments seems to be a pretty tractable problem. There is an assumption there that the number structure created by the national number administrator is the same as the structure within the ENUM tree. This is only true in the pathological case of a fully populated tree. In User ENUM that simply will not be the case. What this draft does is allow the manager of a part of an ENUM tree to describe the structure of that part of the tree and thereby make the dialling process more efficient. In the case of User ENUM this could be the T1 registry. As numbers are registered with them they would create and/or modify send-n records higher up the tree from where the numbers are provisioned. These send-n records would therefore be quite dynamic, responding to the local growth in user ENUM. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 14:58:54 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9623E28C312; Wed, 9 Apr 2008 14:58: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 0935E28C305 for ; Wed, 9 Apr 2008 14:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 IaPEZErqmePY for ; Wed, 9 Apr 2008 14:58:53 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1F7BD28C264 for ; Wed, 9 Apr 2008 14:58:53 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjiJt-0001oD-EP; Wed, 09 Apr 2008 16:59:05 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> Date: Wed, 9 Apr 2008 17:59:08 -0400 Message-ID: <081701c89a8c$f1764ca0$640fa8c0@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: AciaiDg/05Q//a23QcKMP6D6F9Kk5wAA0TIg 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] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 are missing the point. The number of digits need to route the call to the correct domain is determined by a more static database which is not subject to public enum implementations. If we can solve the entire route-to-the-domain problem simply, without requiring deployment of user enum, that is, in my opinion, a better answer. Once you get to the domain, there is more routing to do. I would prefer that the domain handle that directly. That is, after all, how SIP works. We route to the domain using one set of mechanisms. Then the domain uses another set of mechanisms to route to the device. Right now, route to the device with variable length TNs is .001% of the problem. The other 99.999% is route to the domain. I think a simple solution to that would be great. I don't think that is an ENUM solution. Brian -----Original Message----- From: Jay Daley [mailto:jay@nominet.org.uk] Sent: Wednesday, April 09, 2008 5:25 PM To: Brian Rosen Cc: enum@ietf.org Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) Brian > I think the mechanism needed by carriers to route calls is a heck of a lot > easier to solve then a mechanism needed by a phone to dial a hotel that > decided on its own how long it's numbers are. > > If you want to generalize to "needed by originators" instead of carriers, it > doesn't change the problem. > > The number of digits needed to route to the termination domain is determined > by a block assignment by a number administrator. There is one per country > of them. Creating a system where we define a way for them to communicate > block assignments seems to be a pretty tractable problem. There is an assumption there that the number structure created by the national number administrator is the same as the structure within the ENUM tree. This is only true in the pathological case of a fully populated tree. In User ENUM that simply will not be the case. What this draft does is allow the manager of a part of an ENUM tree to describe the structure of that part of the tree and thereby make the dialling process more efficient. In the case of User ENUM this could be the T1 registry. As numbers are registered with them they would create and/or modify send-n records higher up the tree from where the numbers are provisioned. These send-n records would therefore be quite dynamic, responding to the local growth in user ENUM. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 15:13:36 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A393A6C41; Wed, 9 Apr 2008 15:13: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 AF6973A6C41 for ; Wed, 9 Apr 2008 15:13: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 8oVghIC4WHN0 for ; Wed, 9 Apr 2008 15:13:35 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id AC6533A6C43 for ; Wed, 9 Apr 2008 15:13:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,631,1199664000"; d="scan'208";a="223222" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 09 Apr 2008 23:13:52 +0100 In-Reply-To: <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Jay Daley Date: Wed, 9 Apr 2008 23:13:51 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 09/04/2008 11:13:52 PM, Serialize complete at 09/04/2008 11:13:52 PM Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > You are missing the point. > > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. No I'm not missing the point - it the incorrect assumption in what you are saying above that I am disagreeing with. The number of digits needed to route a call is not determined by an independent static database, it is determined by the numbers provisioned in the ENUM trees, which in turn creates the structure of that tree. This draft is a way of describing that structure. > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. That is, after all, how SIP works. > We route to the domain using one set of mechanisms. Then the domain uses > another set of mechanisms to route to the device. > > Right now, route to the device with variable length TNs is .001% of the > problem. The other 99.999% is route to the domain. I think a simple > solution to that would be great. I don't think that is an ENUM solution. I have no objection to anyone working on that further routing. But nobody in their right mind who runs a user ENUM tree (or other ENUM tree) would run a SIP server that just deals with that further routing and then add a NAPTR for that SIP server at every non-terminal point in their ENUM tree, if they could use send-n instead. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 15:49:27 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B262F28C1C3; Wed, 9 Apr 2008 15:49: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 5B41A3A6BC0 for ; Wed, 9 Apr 2008 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=1.971, 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 IR-uAJDvgz4M for ; Wed, 9 Apr 2008 15:49:25 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id E92CC28C172 for ; Wed, 9 Apr 2008 15:49:24 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 732A98E963; Wed, 9 Apr 2008 23:49:43 +0100 (BST) Message-Id: From: Lawrence Conroy To: Jay Daley In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 23:49:43 +0100 References: X-Mailer: Apple Mail (2.919.2) Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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, Brian, folks, must resist - nope - I can't. This one has finally reached my threshold. Jay - I know that you ARE aware of Ofcom's number plan docs. These have absolutely F. all to do with ENUM, or LDAP, or any other implementation. They are a representation of the national number plan in the UK, and they DO give the digit length for each block. From this can be derived: (i) the set of general prefix-dependent number length rules, AND (ii) the number of digits needed to determine the route for calls to numbers in any of these blocks. [NB - (i) and (ii) ARE NOT THE SAME]. Looks pretty static to me (qua Ofcom-anointed number plan changes). Given that ENUM-like schemes are partitioned on a digit-by-digit basis, one can reflect these digit length (and routing determination length) values in DNS. Of course this is not kosher in ENUM, as these records will not be at leaf nodes in the tree, and ENUM is for fully qualified E.164 numbers ONLY. Re. your earlier comment on it not being possible in user ENUM - this is not a technical/protocol argument. Your nation state may have chosen to require each entry anywhere in the tree to be under the control of a subscriber OR NOT BE THERE AT ALL, but that is only one choice. Other nation states/ regions may allow (or even require) carrier control over nodes in the tree, or the NRA may retain control over them, or give up entirely on DNS as a bad job (e.g. USA/North America). It seems to me perfectly reasonable to consider other means of publishing or disseminating this (meta-)data. DNS is not necessary, particularly with such bizarre data models as seem to be proposed by NICC. all the best, Lawrence On 9 Apr 2008, at 23:13, Jay Daley wrote: > Brian > >> You are missing the point. >> >> The number of digits need to route the call to the correct domain is >> determined by a more static database which is not subject to public >> enum >> implementations. > > No I'm not missing the point - it the incorrect assumption in what > you are > saying above that I am disagreeing with. The number of digits > needed to > route a call is not determined by an independent static database, it > is > determined by the numbers provisioned in the ENUM trees, which in turn > creates the structure of that tree. This draft is a way of describing > that structure. > >> Once you get to the domain, there is more routing to do. I would >> prefer >> that the domain handle that directly. That is, after all, how SIP > works. >> We route to the domain using one set of mechanisms. Then the domain > uses >> another set of mechanisms to route to the device. >> >> Right now, route to the device with variable length TNs is .001% of >> the >> problem. The other 99.999% is route to the domain. I think a simple >> solution to that would be great. I don't think that is an ENUM > solution. > > I have no objection to anyone working on that further routing. But > nobody > in their right mind who runs a user ENUM tree (or other ENUM tree) > would > run a SIP server that just deals with that further routing and then > add a > NAPTR for that SIP server at every non-terminal point in their ENUM > tree, > if they could use send-n instead. > > 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 Wed Apr 9 15:54:12 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E353A6CA7; Wed, 9 Apr 2008 15:54: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 EC0CD3A6CA7 for ; Wed, 9 Apr 2008 15:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.735, 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 BfWZQpQEnvn9 for ; Wed, 9 Apr 2008 15:54:07 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id CB4CE3A6C6C for ; Wed, 9 Apr 2008 15:54:07 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjjBM-00069l-5E; Wed, 09 Apr 2008 17:54:20 -0500 From: "Brian Rosen" To: "'Jay Daley'" References: <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> Date: Wed, 9 Apr 2008 18:54:23 -0400 Message-ID: <081901c89a94$a95dc030$640fa8c0@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: AciajvxcJGPtI078T3KJ+fpgFnaM6AAAfn9Q 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] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Here is an example of the authoritative data we're trying to get at, copied from ITU Bulletin 901: Rwanda (country code +250) Communication of 9.I.2008: The Agence Rwandaise de R=E9gulation des Services d'Utilit=E9 Publique, Kig= ali, announces the current National Numbering Plan (NNP) of Rwanda. A new numbering plan is under preparation and will be communicated as soon as it is available. Country code +250 International prefix 00 Overview: Minimum number length (excluding the country code): six (6) digits Maximum number length (excluding the country code): eight (8) digits Details of numbering scheme: (1) (2) (3) (4) (5) N(S)N (National (Significant) Number) N(S)N number length Usage of E.164 Number Operator Additional information Maximum length Minimum length = 5YXXXX 5YZXXX or 5YZXXXXX 8 digits 6 digits Geographic number for fixed telephony services Rwandatel Digit =935=94 identifies the Rwandatel company: Y and Z identify the regional base used in giving telephone numbers. Y, Z and X form the Subscriber Number (SN). 05XXXXXX 8 digits 8 digits Non-geographic number for digital mobile telephony services (e.g. CDMA) Rwandatel =9305=94 digits identify the Rwandatel company and then X forms the Subscriber Number (SN). 06YZXXXX 8 digits 8 digits Geographic number for fixed telephony services Artel =9306=94 digits identify the Artel company; Y and Z identify the regional base used in giving telephone numbers. Y, Z and X form the Subscriber Number (SN). 08XXXXXX 8 digits 8 digits Non-geographic number for digital mobile telephony services (e.g. GSM) MTN Rwanda cell =9308=94 digits identify the MTN Rwanda cell and then X forms the Subscriber Number (SN). 03XXXXXX 8 digits 8 digits Non-geographic number for digital mobile telephony services (e.g. GSM) MTN Rwanda cell =9303=94 digits identify the MTN Rwanda cell and then X identifies the Subscriber Number (SN). It's possible to reflect that in an enum tree, but it's certainly not the only way. This is all the information you need to get a call routed to the correct domain in country code +250. There isn't, but if there was a block that was 6-8 digits, with the last 1 or 2 digits determined by the end domain, the information needed to route the call to the end domain would be in this table. = The problem I have with doing this in enum is that we need the data for all countries to run any form of routing: public, infrastructure or private ENUM, TRIP or any other way. If there is no user enum deployed for any country, we need this data anyway. We need a way to encode the above data and distribute it for every country instead of the ITU bulletin that the table is copied from. That is the problem. The shape of a non existent public enum tree has nothing to do with that. Another little tidbit. Often, the number plan administer announces a change before the change is in effect. They include an effectivity date. Some times, they communicate that there is a period of time where old and new versions of the number plan will work. Whatever we do has to communicate that data. One way to look at the disagreement we are having is that I'm interested in providing a way for some entity building an ENUM T1 to know what the shape of the T1 is. You are interested in communicating to a user of this T1 how to use it. You have to solve my problem before you solve yours. I think once you solve my problem, everyone can use that solution pretty effectively, and they won't need you to solve it. That may not be the case, but I think we have to solve my problem first. Then we can see if it works for everyone. = Brian -----Original Message----- From: Jay Daley [mailto:jay@nominet.org.uk] = Sent: Wednesday, April 09, 2008 6:14 PM To: Brian Rosen Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) Brian > You are missing the point. > = > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. = No I'm not missing the point - it the incorrect assumption in what you are = saying above that I am disagreeing with. The number of digits needed to = route a call is not determined by an independent static database, it is = determined by the numbers provisioned in the ENUM trees, which in turn = creates the structure of that tree. This draft is a way of describing = that structure. > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. That is, after all, how SIP = works. > We route to the domain using one set of mechanisms. Then the domain = uses > another set of mechanisms to route to the device. > > Right now, route to the device with variable length TNs is .001% of the > problem. The other 99.999% is route to the domain. I think a simple > solution to that would be great. I don't think that is an ENUM = solution. I have no objection to anyone working on that further routing. But nobody = in their right mind who runs a user ENUM tree (or other ENUM tree) would = run a SIP server that just deals with that further routing and then add a = NAPTR for that SIP server at every non-terminal point in their ENUM tree, = if they could use send-n instead. = Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 16:01:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CD33A6C75; Wed, 9 Apr 2008 16:01: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 E54583A6B7B for ; Wed, 9 Apr 2008 16:01:56 -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 BzGytDZeS0Pe for ; Wed, 9 Apr 2008 16:01:56 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id DBB683A6B26 for ; Wed, 9 Apr 2008 16:01:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,631,1199664000"; d="scan'208";a="223702" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 10 Apr 2008 00:02:14 +0100 In-Reply-To: To: Lawrence Conroy MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Jay Daley Date: Thu, 10 Apr 2008 00:02:13 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 10/04/2008 12:02:13 AM, Serialize complete at 10/04/2008 12:02:13 AM Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > Jay - I know that you ARE aware of Ofcom's number plan docs. These have > absolutely F. all to do with ENUM, or LDAP, or any other implementation. > They are a representation of the national number plan in the UK, and > they > DO give the digit length for each block. From this can be derived: > (i) the set of general prefix-dependent number length rules, AND > (ii) the number of digits needed to determine the route for calls to > numbers in any of these blocks. > [NB - (i) and (ii) ARE NOT THE SAME]. > Looks pretty static to me (qua Ofcom-anointed number plan changes). Neither of those are the ENUM tree!! There is an idealised state of the ENUM tree if is populated with every number in the national number plan but that is not going to happen. The send-n proposal is about describing the ACTUAL structure not the idealised structure. That is not static and not derivable from either (i) or (ii) above. > Given that ENUM-like schemes are partitioned on a digit-by-digit > basis, one > can reflect these digit length (and routing determination length) > values in > DNS. Of course this is not kosher in ENUM, as these records will not > be at > leaf nodes in the tree, and ENUM is for fully qualified E.164 numbers > ONLY. Is that by dogma or design? > It seems to me perfectly reasonable to consider other means of > publishing > or disseminating this (meta-)data. DNS is not necessary, particularly > with > such bizarre data models as seem to be proposed by NICC. I agree entirely that we need a better, standardised way of representing (i) and (ii) above. Some companies even make a living on creating such tables for their customers. But that is entirely orthogonal to send-n. Jay _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 9 19:15:36 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8DA3A69A5; Wed, 9 Apr 2008 19:15: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 8BF743A69A5 for ; Wed, 9 Apr 2008 19:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yA9VjiKjUeBQ for ; Wed, 9 Apr 2008 19:15:30 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id CE8CF3A6988 for ; Wed, 9 Apr 2008 19:15:04 -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 m3A2EMV4030873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 19:14:24 -0700 From: "Richard Shockey" To: "'Jay Daley'" , "'Lawrence Conroy'" References: In-Reply-To: Date: Wed, 9 Apr 2008 22:14:59 -0400 Message-ID: <044a01c89ab0$af1b9080$0d52b180$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcialaPcPocG8lfSRcOQkCbvIlMcKgAGjnmA Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org Subject: [Enum] Chair Question... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Well as a purely administrative issue .... I'm assuming someone wants to present send-n or successor document in Dublin? Between this a revised UNUSED and of course, Source URI I'm going to need a 2 hour slot ? Correct? Working groups have "long tails" but really ... > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Jay Daley > Sent: Wednesday, April 09, 2008 7:02 PM > To: Lawrence Conroy > Cc: enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: > New draft - draft-bellis-enum-send-n-00) > > Lawrence > > > Jay - I know that you ARE aware of Ofcom's number plan docs. These > have > > absolutely F. all to do with ENUM, or LDAP, or any other > implementation. > > They are a representation of the national number plan in the UK, and > > they > > DO give the digit length for each block. From this can be derived: > > (i) the set of general prefix-dependent number length rules, AND > > (ii) the number of digits needed to determine the route for calls to > > numbers in any of these blocks. > > [NB - (i) and (ii) ARE NOT THE SAME]. > > Looks pretty static to me (qua Ofcom-anointed number plan changes). > > Neither of those are the ENUM tree!! There is an idealised state of > the > ENUM tree if is populated with every number in the national number > plan > but that is not going to happen. > > The send-n proposal is about describing the ACTUAL structure not the > idealised structure. That is not static and not derivable from either > (i) > or (ii) above. > > > Given that ENUM-like schemes are partitioned on a digit-by-digit > > basis, one > > can reflect these digit length (and routing determination length) > > values in > > DNS. Of course this is not kosher in ENUM, as these records will not > > be at > > leaf nodes in the tree, and ENUM is for fully qualified E.164 > numbers > > ONLY. > > Is that by dogma or design? > > > It seems to me perfectly reasonable to consider other means of > > publishing > > or disseminating this (meta-)data. DNS is not necessary, > particularly > > with > > such bizarre data models as seem to be proposed by NICC. > > I agree entirely that we need a better, standardised way of > representing > (i) and (ii) above. Some companies even make a living on creating > such > tables for their customers. But that is entirely orthogonal to send- > n. > > 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 Wed Apr 9 22:17:22 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C9D3A69AF; Wed, 9 Apr 2008 22:17: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 8457D3A6A44 for ; Wed, 9 Apr 2008 22:17:21 -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 JPu0rjm2FDmy for ; Wed, 9 Apr 2008 22:17:20 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by core3.amsl.com (Postfix) with ESMTP id 899713A686B for ; Wed, 9 Apr 2008 22:17:20 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id D70D15BAB; Thu, 10 Apr 2008 05:17:38 +0000 (GMT) Received: from cmsapps06.cms.usa.net [165.212.11.129] by cmsout03.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID771mDJFRn3735X03; Thu, 10 Apr 2008 05:17:39 -0000 X-USANET-Source: 165.212.11.129 IN richard@stastny.com cmsapps06.cms.usa.net X-USANET-MsgId: XID771mDJFRn3735X03 Received: from richard-stastnys-computer.local [86.59.61.62] by cmsapps06.cms.usa.net (ESMTPA/stastny@usa.net) via mtad (C8.MAIN.3.40M) with ESMTPA id 620mDJFRj0290M29; Thu, 10 Apr 2008 05:17:36 -0000 X-USANET-Auth: 86.59.61.62 AUTH stastny@usa.net richard-stastnys-computer.local Message-ID: <47FDA2E8.60809@stastny.com> Date: Thu, 10 Apr 2008 07:17:28 +0200 From: Richard Stastny User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brian Rosen References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> In-Reply-To: <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> Z-USANET-MsgId: XID620mDJFRK0290X29 Cc: 'Jay Daley' , enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. If we can solve the entire route-to-the-domain problem > simply, without requiring deployment of user enum, that is, in my opinion, a > better answer. > > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. Folks, I am watching this discussion since some time and I am wondering. There seems to be an understanding of numbering from 30 years in the past: one uses number blocks to route to the domain (= operator) and then the operator does rest Never heard about number portability ? Regardless of User or Infrastructure ENUM the routing to the domain has to be per number finally. The domain has to find out where the user really is connected. The Rwanda example is nice and was discussed in Austria 1985 when new carriers are introduced, because the routing was simple, but never implemented because it does not support NP, beside other drawbacks. Richard Brian Rosen wrote: > You are missing the point. > > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. If we can solve the entire route-to-the-domain problem > simply, without requiring deployment of user enum, that is, in my opinion, a > better answer. > > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. That is, after all, how SIP works. > We route to the domain using one set of mechanisms. Then the domain uses > another set of mechanisms to route to the device. > > Right now, route to the device with variable length TNs is .001% of the > problem. The other 99.999% is route to the domain. I think a simple > solution to that would be great. I don't think that is an ENUM solution. > > Brian > > > > > -----Original Message----- > From: Jay Daley [mailto:jay@nominet.org.uk] > Sent: Wednesday, April 09, 2008 5:25 PM > To: Brian Rosen > Cc: enum@ietf.org > Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New > draft - draft-bellis-enum-send-n-00) > > Brian > >> I think the mechanism needed by carriers to route calls is a heck of a > lot >> easier to solve then a mechanism needed by a phone to dial a hotel that >> decided on its own how long it's numbers are. >> >> If you want to generalize to "needed by originators" instead of > carriers, it >> doesn't change the problem. >> >> The number of digits needed to route to the termination domain is > determined >> by a block assignment by a number administrator. There is one per > country >> of them. Creating a system where we define a way for them to > communicate >> block assignments seems to be a pretty tractable problem. > > There is an assumption there that the number structure created by the > national number administrator is the same as the structure within the ENUM > tree. This is only true in the pathological case of a fully populated > tree. In User ENUM that simply will not be the case. > > What this draft does is allow the manager of a part of an ENUM tree to > describe the structure of that part of the tree and thereby make the > dialling process more efficient. > > In the case of User ENUM this could be the T1 registry. As numbers are > registered with them they would create and/or modify send-n records higher > up the tree from where the numbers are provisioned. These send-n records > would therefore be quite dynamic, responding to the local growth in user > ENUM. > > 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 Apr 10 06:01:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC293A6A73; Thu, 10 Apr 2008 06:01: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 315C93A67D8 for ; Thu, 10 Apr 2008 06:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 Jxo5jc4+rpuy for ; Thu, 10 Apr 2008 06:00:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 5193128C4F2 for ; Thu, 10 Apr 2008 06:00:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjwOI-0000lm-Ai; Thu, 10 Apr 2008 08:00:34 -0500 From: "Brian Rosen" To: "'Richard Stastny'" References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> <47FDA2E8.60809@stastny.com> Date: Thu, 10 Apr 2008 09:00:35 -0400 Message-ID: <08d001c89b0a$dfbcf4e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47FDA2E8.60809@stastny.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciayjOc3/Gv0yUsSRmBBEzggkU9JgAP74cw 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: 'Jay Daley' , enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Nice to hear from you, hope you are enjoying your retirement and numbering blocks still have great relevance 30 years later. Nearly every country has number block assignments. The information we are trying to extract is the length of a number, although it does turn out that the carrier assignment data is also useful, and as long as we're providing a mechanism to extract the number plan from the number administrator, we might as well get the assignment data. Even in the U.S., which has a single length, knowledge of the block assignments is useful to know: 1) What is a valid number 2) Which carrier owns the number when the number has not been ported. I know of very few number portability databases where every number ever issued is in the database. Having access, in one form or another, to the database only gets you so far. However, I'd like to keep this discussion on track, which is determining the number of digits in a number needed to route. Brian -----Original Message----- From: Richard Stastny [mailto:richard@stastny.com] Sent: Thursday, April 10, 2008 1:17 AM To: Brian Rosen Cc: 'Jay Daley'; enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. If we can solve the entire route-to-the-domain problem > simply, without requiring deployment of user enum, that is, in my opinion, a > better answer. > > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. Folks, I am watching this discussion since some time and I am wondering. There seems to be an understanding of numbering from 30 years in the past: one uses number blocks to route to the domain (= operator) and then the operator does rest Never heard about number portability ? Regardless of User or Infrastructure ENUM the routing to the domain has to be per number finally. The domain has to find out where the user really is connected. The Rwanda example is nice and was discussed in Austria 1985 when new carriers are introduced, because the routing was simple, but never implemented because it does not support NP, beside other drawbacks. Richard Brian Rosen wrote: > You are missing the point. > > The number of digits need to route the call to the correct domain is > determined by a more static database which is not subject to public enum > implementations. If we can solve the entire route-to-the-domain problem > simply, without requiring deployment of user enum, that is, in my opinion, a > better answer. > > Once you get to the domain, there is more routing to do. I would prefer > that the domain handle that directly. That is, after all, how SIP works. > We route to the domain using one set of mechanisms. Then the domain uses > another set of mechanisms to route to the device. > > Right now, route to the device with variable length TNs is .001% of the > problem. The other 99.999% is route to the domain. I think a simple > solution to that would be great. I don't think that is an ENUM solution. > > Brian > > > > > -----Original Message----- > From: Jay Daley [mailto:jay@nominet.org.uk] > Sent: Wednesday, April 09, 2008 5:25 PM > To: Brian Rosen > Cc: enum@ietf.org > Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New > draft - draft-bellis-enum-send-n-00) > > Brian > >> I think the mechanism needed by carriers to route calls is a heck of a > lot >> easier to solve then a mechanism needed by a phone to dial a hotel that >> decided on its own how long it's numbers are. >> >> If you want to generalize to "needed by originators" instead of > carriers, it >> doesn't change the problem. >> >> The number of digits needed to route to the termination domain is > determined >> by a block assignment by a number administrator. There is one per > country >> of them. Creating a system where we define a way for them to > communicate >> block assignments seems to be a pretty tractable problem. > > There is an assumption there that the number structure created by the > national number administrator is the same as the structure within the ENUM > tree. This is only true in the pathological case of a fully populated > tree. In User ENUM that simply will not be the case. > > What this draft does is allow the manager of a part of an ENUM tree to > describe the structure of that part of the tree and thereby make the > dialling process more efficient. > > In the case of User ENUM this could be the T1 registry. As numbers are > registered with them they would create and/or modify send-n records higher > up the tree from where the numbers are provisioned. These send-n records > would therefore be quite dynamic, responding to the local growth in user > ENUM. > > 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 Apr 10 08:42:52 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54B83A6DA7; Thu, 10 Apr 2008 08:42: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 3929828C154 for ; Thu, 10 Apr 2008 08:42:51 -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 ROAWBgA43+PD for ; Thu, 10 Apr 2008 08:42:47 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by core3.amsl.com (Postfix) with ESMTP id 316D128C113 for ; Thu, 10 Apr 2008 08:42:47 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by cmsout02.mbox.net (Postfix) with ESMTP id EDC655E8C; Thu, 10 Apr 2008 15:42:59 +0000 (GMT) Received: from cmsapps04.cms.usa.net [165.212.11.133] by cmsout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID837mDJPra5894X02; Thu, 10 Apr 2008 15:43:00 -0000 X-USANET-Source: 165.212.11.133 IN richard@stastny.com cmsapps04.cms.usa.net X-USANET-MsgId: XID837mDJPra5894X02 Received: from richard-stastnys-computer.local [86.59.61.62] by cmsapps04.cms.usa.net (ESMTPA/stastny@usa.net) via mtad (C8.MAIN.3.40M) with ESMTPA id 073mDJPQ50447M40; Thu, 10 Apr 2008 15:42:56 -0000 X-USANET-Auth: 86.59.61.62 AUTH stastny@usa.net richard-stastnys-computer.local Message-ID: <47FE3579.9050906@stastny.com> Date: Thu, 10 Apr 2008 17:42:49 +0200 From: Richard Stastny User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brian Rosen References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> <47FDA2E8.60809@stastny.com> <08d001c89b0a$dfbcf4e0$640fa8c0@cis.neustar.com> In-Reply-To: <08d001c89b0a$dfbcf4e0$640fa8c0@cis.neustar.com> Z-USANET-MsgId: XID073mDJPQ50447X40 Cc: 'Jay Daley' , enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 know of very few number portability databases where every number ever > issued is in the database. Having access, in one form or another, to the > database only gets you so far. > > However, I'd like to keep this discussion on track, which is determining the > number of digits in a number needed to route. Infrastructure ENUM is a replacement for All Call Queery (ACQ) It only makes sense if a certain country or number range is fully implemented. The simplest and easiest way to do so is to implement only a Tier 1 datebase (contrary to User ENUM), where all E.164 numbers of the number range are entered and are pointing to the carrier hosting the number. The problem I see here with send-n is that you cannot use this simple structure here and have to make zone delegations below to hold the send-n NAPTRs. In DE and AT, the whole thing does not work anyway, because e.g. you may have +43 1 9793321 and +43 1 97933221 and +43 1 97933222 and this is a carriers choice. regards Richard Brian Rosen wrote: > Richard > > Nice to hear from you, hope you are enjoying your retirement and numbering > blocks still have great relevance 30 years later. > > Nearly every country has number block assignments. The information we are > trying to extract is the length of a number, although it does turn out that > the carrier assignment data is also useful, and as long as we're providing a > mechanism to extract the number plan from the number administrator, we might > as well get the assignment data. Even in the U.S., which has a single > length, knowledge of the block assignments is useful to know: > 1) What is a valid number > 2) Which carrier owns the number when the number has not been ported. > > I know of very few number portability databases where every number ever > issued is in the database. Having access, in one form or another, to the > database only gets you so far. > > However, I'd like to keep this discussion on track, which is determining the > number of digits in a number needed to route. > > Brian > > -----Original Message----- > From: Richard Stastny [mailto:richard@stastny.com] > Sent: Thursday, April 10, 2008 1:17 AM > To: Brian Rosen > Cc: 'Jay Daley'; enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience > > > The number of digits need to route the call to the correct domain is > > determined by a more static database which is not subject to public enum > > implementations. If we can solve the entire route-to-the-domain problem > > simply, without requiring deployment of user enum, that is, in my > opinion, a > > better answer. > > > > Once you get to the domain, there is more routing to do. I would prefer > > that the domain handle that directly. > > Folks, > > I am watching this discussion since some time and > I am wondering. > > There seems to be an understanding of numbering > from 30 years in the past: > > one uses number blocks to route to the > domain (= operator) and then the operator does > rest > > Never heard about number portability ? > > Regardless of User or Infrastructure ENUM > the routing to the domain has to be > per number finally. The domain has to > find out where the user really is connected. > > The Rwanda example is nice and was discussed > in Austria 1985 when new carriers are introduced, > because the routing was simple, but never implemented > because it does not support NP, beside other drawbacks. > > Richard > > > > Brian Rosen wrote: >> You are missing the point. >> >> The number of digits need to route the call to the correct domain is >> determined by a more static database which is not subject to public enum >> implementations. If we can solve the entire route-to-the-domain problem >> simply, without requiring deployment of user enum, that is, in my opinion, > a >> better answer. >> >> Once you get to the domain, there is more routing to do. I would prefer >> that the domain handle that directly. That is, after all, how SIP works. >> We route to the domain using one set of mechanisms. Then the domain uses >> another set of mechanisms to route to the device. >> >> Right now, route to the device with variable length TNs is .001% of the >> problem. The other 99.999% is route to the domain. I think a simple >> solution to that would be great. I don't think that is an ENUM solution. >> >> Brian >> >> >> >> >> -----Original Message----- >> From: Jay Daley [mailto:jay@nominet.org.uk] >> Sent: Wednesday, April 09, 2008 5:25 PM >> To: Brian Rosen >> Cc: enum@ietf.org >> Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New >> draft - draft-bellis-enum-send-n-00) >> >> Brian >> >>> I think the mechanism needed by carriers to route calls is a heck of a >> lot >>> easier to solve then a mechanism needed by a phone to dial a hotel that >>> decided on its own how long it's numbers are. >>> >>> If you want to generalize to "needed by originators" instead of >> carriers, it >>> doesn't change the problem. >>> >>> The number of digits needed to route to the termination domain is >> determined >>> by a block assignment by a number administrator. There is one per >> country >>> of them. Creating a system where we define a way for them to >> communicate >>> block assignments seems to be a pretty tractable problem. >> There is an assumption there that the number structure created by the >> national number administrator is the same as the structure within the ENUM > >> tree. This is only true in the pathological case of a fully populated >> tree. In User ENUM that simply will not be the case. >> >> What this draft does is allow the manager of a part of an ENUM tree to >> describe the structure of that part of the tree and thereby make the >> dialling process more efficient. >> >> In the case of User ENUM this could be the T1 registry. As numbers are >> registered with them they would create and/or modify send-n records higher > >> up the tree from where the numbers are provisioned. These send-n records >> would therefore be quite dynamic, responding to the local growth in user >> ENUM. >> >> 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 Apr 10 09:21:29 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C433A6A5D; Thu, 10 Apr 2008 09:21: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 28BFF3A6C49 for ; Thu, 10 Apr 2008 01:36: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 Y4qUvmsncnvj for ; Thu, 10 Apr 2008 01:36:53 -0700 (PDT) Received: from mail175.messagelabs.com (mail175.messagelabs.com [85.158.138.67]) by core3.amsl.com (Postfix) with SMTP id CFDB23A6819 for ; Thu, 10 Apr 2008 01:36:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cw.com X-Msg-Ref: server-6.tower-175.messagelabs.com!1207816582!9741815!21 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 23735 invoked from network); 10 Apr 2008 08:37:09 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-6.tower-175.messagelabs.com with SMTP; 10 Apr 2008 08:37:09 -0000 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 09:36:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 09:36:36 +0100 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D604673725@GBCWSWIEM002.ad.plc.cwintra.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Overlap dialing user experience (Re: I-DAction: New draft - draft-bellis-enum-send-n-00) Thread-Index: AcialAUZ08Ro+p0IT2eC7dirF0PCHAATWO4Q From: "Rosbotham, Paul" To: "Lawrence Conroy" , "Jay Daley" , X-OriginalArrivalTime: 10 Apr 2008 08:36:50.0420 (UTC) FILETIME=[056C5340:01C89AE6] X-Mailman-Approved-At: Thu, 10 Apr 2008 09:21:28 -0700 Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 all I too have been watching this debate with interest & biting my tongue, but threshold reached. I chair the UK telecoms standards agency. The concept of Send-N was developed there for usage in the numbering database that UK industry is currently procuring (more below), from a requirement agreed by a group that contains every major UK telco. So, yes, we do sort of know that Ofcom provides a numbering plan because it's our day-to-day business. We also know what it's issues are hence why we want something better. I should at the outset say - I'm ambivalent about bringing Send-N into the international domain & potential use of it in user-ENUM; I can see the attractions & issues, but my main concern is the introduction of our national database that I have a regulatory obligation to implement. - I apologise that a lot of this is UK-centric, however it is worthy of mention here because the issues are pretty much replicated wherever there's a variable length numbering plan. So, to where Send-N originally arose. We are currently putting together a database that is notionally for support of portability, but (subject to the economics) may well contain the association of every number to the terminating domain. It will offer a real-time query interface using an ENUM-like approach, but most telcos will in practise download the whole thing into their networks and query locally (again, in many cases using a network-internal ENUM approach). As Lawrence says, it is possible to take the Ofcom numbering plan and embed it into your callservers/switches, and use that to ascertain when you've got sufficient digits to query the database. However, - errors do creep into the plan. - for reasons that are too complicated/irrelevant to go into here, it isn't exhaustive, in particular in the 0800 ranges that Clive Feather mentioned in an earlier mail. - it is a large amount of data that uses significant technical resources on callservers/switches and human resources to keep up to date. ...for this reason I think every telco to some degree relies on interdigit timers in those areas of the plan with more variability. Now, given we're introducing a common database of numbers, the users of that database (ie the telcos) felt it appropriate to add functionality to it to indicate when it had been queried with insufficient digits. Otherwise, we yield the benefit of not having to break out each individual number range for routeing purposes on our callservers (database is telling you that info), only to lose it because we have to break them out to check we've got enough digits prior to querying the database. A sensible telco won't be querying the database each time an end-user keys a digit, there would still be some basic number length info in the callserver. For example, in the geographic code 01744 I know there are 10 & 11 digit numbers so will query after 10, receiving a Send-1 if it turns out the individual level within 01744 is one which is 11 digits long. Conversely, 01772 has only 11 digit numbers so I'll query after 11. This means the number length tree I have to hold on my nodes is <1000 entries long, versus nearer 25,000 entries now. There's a valid question of whether Send-N should have been in the same database as the individual numbers, but from our perspective we're building a common/private database, and it makes little sense to build/have to query two separate databases versus putting it in a single one. As an individual number database, we don't have wildcards, and in any case in a regime with portability meaning the numbering space is highly fragmented they're of little value. I doubt there are any number ranges in the UK that are used solely by a single telco with no exported numbers so wildcarding based on number range simply doesn't work (as highlighted by Richard Stastny's mail). As I say, I'm ambivalent on the usage in public ENUM. Certainly there appears to have been a misconception to date that ENUM clients will know when the user has completed dialling. For fixed length plans and applications where the customer has a "send"/"call" key that is the case, but for blackphone support it certainly isn't without using interdigit timeouts. The ITU information has been mentioned as helpful. Thanks for that, I kicked off the initiative back in 2000 so glad to hear it's added some value. However, it really isn't much more than a map to provide clues (either to number length or where to go to try to find out)...it certainly isn't a reliable or comprehensive source of data for originating telcos to know how many digits to expect on international calls. Regards Paul Rosbotham Manager, Interconnect Strategy & Technology Regulation Cable&Wireless Europe, Asia and US Direct Dial: +44 1772 451506 Mobile: +44 7957 805573 www.cw.com -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Lawrence Conroy Sent: 09 April 2008 23:50 To: Jay Daley Cc: enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New draft - draft-bellis-enum-send-n-00) Hi Jay, Brian, folks, must resist - nope - I can't. This one has finally reached my threshold. Jay - I know that you ARE aware of Ofcom's number plan docs. These have absolutely F. all to do with ENUM, or LDAP, or any other implementation. They are a representation of the national number plan in the UK, and they DO give the digit length for each block. From this can be derived: (i) the set of general prefix-dependent number length rules, AND (ii) the number of digits needed to determine the route for calls to numbers in any of these blocks. [NB - (i) and (ii) ARE NOT THE SAME]. Looks pretty static to me (qua Ofcom-anointed number plan changes). 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 Apr 10 09:40:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30F73A6AD8; Thu, 10 Apr 2008 09:40: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 649DA3A68C6 for ; Thu, 10 Apr 2008 09:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.718, 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 PkBZDzXTp97v for ; Thu, 10 Apr 2008 09:40:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id C86023A6D4A for ; Thu, 10 Apr 2008 09:40:35 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JjzpT-0004Gl-Oc; Thu, 10 Apr 2008 11:40:52 -0500 From: "Brian Rosen" To: "'Richard Stastny'" References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> <47FDA2E8.60809@stastny.com> <08d001c89b0a$dfbcf4e0$640fa8c0@cis.neustar.com> <47FE3579.9050906@stastny.com> Date: Thu, 10 Apr 2008 12:40:52 -0400 Message-ID: <094401c89b29$a5dabf40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47FE3579.9050906@stastny.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcibIY18XJy5WjLuQGabNy6KR7wTnQAAVrfA 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: 'Jay Daley' , enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Staying on track, the problem I want solve is to determine how many digits are needed to route to the terminal domain. In DE and AT, you have this variable length capability. I understand that. I would expect that if I found the equivalent number plan in the ITU bulletin for Austria, I would find that there was a block something like 1 979 XXXX with a min of 8 and max of 9 digits. That is enough information to figure out when there are enough digits to query ENUM, and is enough information to construct a T1 that works. I would need access to the number portability database to route the call if this block was subject to portability. Brian -----Original Message----- From: Richard Stastny [mailto:richard@stastny.com] Sent: Thursday, April 10, 2008 11:43 AM To: Brian Rosen Cc: 'Jay Daley'; enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience Brian, > I know of very few number portability databases where every number ever > issued is in the database. Having access, in one form or another, to the > database only gets you so far. > > However, I'd like to keep this discussion on track, which is determining the > number of digits in a number needed to route. Infrastructure ENUM is a replacement for All Call Queery (ACQ) It only makes sense if a certain country or number range is fully implemented. The simplest and easiest way to do so is to implement only a Tier 1 datebase (contrary to User ENUM), where all E.164 numbers of the number range are entered and are pointing to the carrier hosting the number. The problem I see here with send-n is that you cannot use this simple structure here and have to make zone delegations below to hold the send-n NAPTRs. In DE and AT, the whole thing does not work anyway, because e.g. you may have +43 1 9793321 and +43 1 97933221 and +43 1 97933222 and this is a carriers choice. regards Richard Brian Rosen wrote: > Richard > > Nice to hear from you, hope you are enjoying your retirement and numbering > blocks still have great relevance 30 years later. > > Nearly every country has number block assignments. The information we are > trying to extract is the length of a number, although it does turn out that > the carrier assignment data is also useful, and as long as we're providing a > mechanism to extract the number plan from the number administrator, we might > as well get the assignment data. Even in the U.S., which has a single > length, knowledge of the block assignments is useful to know: > 1) What is a valid number > 2) Which carrier owns the number when the number has not been ported. > > I know of very few number portability databases where every number ever > issued is in the database. Having access, in one form or another, to the > database only gets you so far. > > However, I'd like to keep this discussion on track, which is determining the > number of digits in a number needed to route. > > Brian > > -----Original Message----- > From: Richard Stastny [mailto:richard@stastny.com] > Sent: Thursday, April 10, 2008 1:17 AM > To: Brian Rosen > Cc: 'Jay Daley'; enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience > > > The number of digits need to route the call to the correct domain is > > determined by a more static database which is not subject to public enum > > implementations. If we can solve the entire route-to-the-domain problem > > simply, without requiring deployment of user enum, that is, in my > opinion, a > > better answer. > > > > Once you get to the domain, there is more routing to do. I would prefer > > that the domain handle that directly. > > Folks, > > I am watching this discussion since some time and > I am wondering. > > There seems to be an understanding of numbering > from 30 years in the past: > > one uses number blocks to route to the > domain (= operator) and then the operator does > rest > > Never heard about number portability ? > > Regardless of User or Infrastructure ENUM > the routing to the domain has to be > per number finally. The domain has to > find out where the user really is connected. > > The Rwanda example is nice and was discussed > in Austria 1985 when new carriers are introduced, > because the routing was simple, but never implemented > because it does not support NP, beside other drawbacks. > > Richard > > > > Brian Rosen wrote: >> You are missing the point. >> >> The number of digits need to route the call to the correct domain is >> determined by a more static database which is not subject to public enum >> implementations. If we can solve the entire route-to-the-domain problem >> simply, without requiring deployment of user enum, that is, in my opinion, > a >> better answer. >> >> Once you get to the domain, there is more routing to do. I would prefer >> that the domain handle that directly. That is, after all, how SIP works. >> We route to the domain using one set of mechanisms. Then the domain uses >> another set of mechanisms to route to the device. >> >> Right now, route to the device with variable length TNs is .001% of the >> problem. The other 99.999% is route to the domain. I think a simple >> solution to that would be great. I don't think that is an ENUM solution. >> >> Brian >> >> >> >> >> -----Original Message----- >> From: Jay Daley [mailto:jay@nominet.org.uk] >> Sent: Wednesday, April 09, 2008 5:25 PM >> To: Brian Rosen >> Cc: enum@ietf.org >> Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New >> draft - draft-bellis-enum-send-n-00) >> >> Brian >> >>> I think the mechanism needed by carriers to route calls is a heck of a >> lot >>> easier to solve then a mechanism needed by a phone to dial a hotel that >>> decided on its own how long it's numbers are. >>> >>> If you want to generalize to "needed by originators" instead of >> carriers, it >>> doesn't change the problem. >>> >>> The number of digits needed to route to the termination domain is >> determined >>> by a block assignment by a number administrator. There is one per >> country >>> of them. Creating a system where we define a way for them to >> communicate >>> block assignments seems to be a pretty tractable problem. >> There is an assumption there that the number structure created by the >> national number administrator is the same as the structure within the ENUM > >> tree. This is only true in the pathological case of a fully populated >> tree. In User ENUM that simply will not be the case. >> >> What this draft does is allow the manager of a part of an ENUM tree to >> describe the structure of that part of the tree and thereby make the >> dialling process more efficient. >> >> In the case of User ENUM this could be the T1 registry. As numbers are >> registered with them they would create and/or modify send-n records higher > >> up the tree from where the numbers are provisioned. These send-n records >> would therefore be quite dynamic, responding to the local growth in user >> ENUM. >> >> 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 Apr 10 09:44:15 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D453F3A6D3B; Thu, 10 Apr 2008 09:44: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 54D523A6C6A for ; Thu, 10 Apr 2008 09:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.079 X-Spam-Level: X-Spam-Status: No, score=-5.079 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, J_CHICKENPOX_21=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 mn3z0AP9HIjq for ; Thu, 10 Apr 2008 09:44:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5B6BA3A6A37 for ; Thu, 10 Apr 2008 09:44:09 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2008 09:44:30 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3AGiU4h003433; Thu, 10 Apr 2008 09:44:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3AGiSF4021483; Thu, 10 Apr 2008 16:44:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 12:44:29 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 12:44:28 -0400 Message-ID: <47FE4408.9050206@cisco.com> Date: Thu, 10 Apr 2008 12:44:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Rosbotham, Paul" References: <9322B78036E1534A99B0BC51DEB0F9D604673725@GBCWSWIEM002.ad.plc.cwintra.com> In-Reply-To: <9322B78036E1534A99B0BC51DEB0F9D604673725@GBCWSWIEM002.ad.plc.cwintra.com> X-OriginalArrivalTime: 10 Apr 2008 16:44:28.0789 (UTC) FILETIME=[24C52250:01C89B2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7733; t=1207845870; x=1208709870; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20Overlap=20dialing=20user=20exp erience=20(Re=3A=09I-DAction=3A=09New=09draft=0A=20-=20draft -bellis-enum-send-n-00) |Sender:=20; bh=r1FbBGGUBnliuttyEUQuvnYrKpQaYm8EhpJkCRyXgdg=; b=XM3k+iTSdbcXkAslo90qZdm5R980qNNcTTkfUBUThsC/sXtofxJ+A92YsK 9nWS5MTDFo0D+gP5HJggLYnlleLZKDu2upbtLlBwJYUldHpVrI52U6JUVwOt euwPe549oGGVLTP/3q8Wnd6HJcpayI52YC7zu+Uxw3zRvfCSMox8U=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Jay Daley , enum@ietf.org, Lawrence Conroy Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New draft - draft-bellis-enum-send-n-00) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Paul R, Your reply was educational to me. Thanks. You talk of this as primarily for SP, and question applicability to user enum. I understand that, I think. But the SP can only do this when it knows there is a call attempt. That works fine when it is a black phone connected to a SP server, sending digits one by one. But what happens when the client phone is itself a sip UA? Even if it is going to delegate the call routing decisions to a SP server, it still has to determine the end of the dial string in order to know when to send an INVITE. So it seems that this DB needs to be accessible from those customer devices. How does that fit into your view? Paul K Rosbotham, Paul wrote: > Hi all > > I too have been watching this debate with interest & biting my tongue, but threshold reached. > > I chair the UK telecoms standards agency. The concept of Send-N was developed there for usage in the numbering database that UK industry is currently procuring (more below), from a requirement agreed by a group that contains every major UK telco. So, yes, we do sort of know that Ofcom provides a numbering plan because it's our day-to-day business. We also know what it's issues are hence why we want something better. > > I should at the outset say > > - I'm ambivalent about bringing Send-N into the international domain & potential use of it in user-ENUM; I can see the attractions & issues, but my main concern is the introduction of our national database that I have a regulatory obligation to implement. > - I apologise that a lot of this is UK-centric, however it is worthy of mention here because the issues are pretty much replicated wherever there's a variable length numbering plan. > > So, to where Send-N originally arose. We are currently putting together a database that is notionally for support of portability, but (subject to the economics) may well contain the association of every number to the terminating domain. It will offer a real-time query interface using an ENUM-like approach, but most telcos will in practise download the whole thing into their networks and query locally (again, in many cases using a network-internal ENUM approach). > > As Lawrence says, it is possible to take the Ofcom numbering plan and embed it into your callservers/switches, and use that to ascertain when you've got sufficient digits to query the database. However, > > - errors do creep into the plan. > - for reasons that are too complicated/irrelevant to go into here, it isn't exhaustive, in particular in the 0800 ranges that Clive Feather mentioned in an earlier mail. > - it is a large amount of data that uses significant technical resources on callservers/switches and human resources to keep up to date. > ...for this reason I think every telco to some degree relies on interdigit timers in those areas of the plan with more variability. > > Now, given we're introducing a common database of numbers, the users of that database (ie the telcos) felt it appropriate to add functionality to it to indicate when it had been queried with insufficient digits. Otherwise, we yield the benefit of not having to break out each individual number range for routeing purposes on our callservers (database is telling you that info), only to lose it because we have to break them out to check we've got enough digits prior to querying the database. > > A sensible telco won't be querying the database each time an end-user keys a digit, there would still be some basic number length info in the callserver. For example, in the geographic code 01744 I know there are 10 & 11 digit numbers so will query after 10, receiving a Send-1 if it turns out the individual level within 01744 is one which is 11 digits long. Conversely, 01772 has only 11 digit numbers so I'll query after 11. This means the number length tree I have to hold on my nodes is <1000 entries long, versus nearer 25,000 entries now. > > There's a valid question of whether Send-N should have been in the same database as the individual numbers, but from our perspective we're building a common/private database, and it makes little sense to build/have to query two separate databases versus putting it in a single one. As an individual number database, we don't have wildcards, and in any case in a regime with portability meaning the numbering space is highly fragmented they're of little value. I doubt there are any number ranges in the UK that are used solely by a single telco with no exported numbers so wildcarding based on number range simply doesn't work (as highlighted by Richard Stastny's mail). > > As I say, I'm ambivalent on the usage in public ENUM. Certainly there appears to have been a misconception to date that ENUM clients will know when the user has completed dialling. For fixed length plans and applications where the customer has a "send"/"call" key that is the case, but for blackphone support it certainly isn't without using interdigit timeouts. The ITU information has been mentioned as helpful. Thanks for that, I kicked off the initiative back in 2000 so glad to hear it's added some value. However, it really isn't much more than a map to provide clues (either to number length or where to go to try to find out)...it certainly isn't a reliable or comprehensive source of data for originating telcos to know how many digits to expect on international calls. > > Regards > > Paul Rosbotham > Manager, Interconnect Strategy & Technology Regulation > Cable&Wireless > Europe, Asia and US > Direct Dial: +44 1772 451506 > Mobile: +44 7957 805573 > www.cw.com > > > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of > Lawrence Conroy > Sent: 09 April 2008 23:50 > To: Jay Daley > Cc: enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New > draft - draft-bellis-enum-send-n-00) > > > Hi Jay, Brian, folks, > must resist - nope - I can't. This one has finally reached my > threshold. > Jay - I know that you ARE aware of Ofcom's number plan docs. These have > absolutely F. all to do with ENUM, or LDAP, or any other implementation. > They are a representation of the national number plan in the UK, and > they > DO give the digit length for each block. From this can be derived: > (i) the set of general prefix-dependent number length rules, AND > (ii) the number of digits needed to determine the route for calls to > numbers in any of these blocks. > [NB - (i) and (ii) ARE NOT THE SAME]. > Looks pretty static to me (qua Ofcom-anointed number plan changes). > > > 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 Thu Apr 10 13:29:37 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DFD3A6C17; Thu, 10 Apr 2008 13:29: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 649263A6CC1 for ; Thu, 10 Apr 2008 13:29:36 -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 WAKLDQr1UDFC for ; Thu, 10 Apr 2008 13:29:35 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by core3.amsl.com (Postfix) with ESMTP id DFFE53A6AB1 for ; Thu, 10 Apr 2008 13:29:34 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id 5078B5B6D; Thu, 10 Apr 2008 20:29:52 +0000 (GMT) Received: from cmsapps05.cms.usa.net [165.212.11.128] by cmsout03.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID671mDJud23595X03; Thu, 10 Apr 2008 20:29:53 -0000 X-USANET-Source: 165.212.11.128 IN richard@stastny.com cmsapps05.cms.usa.net X-USANET-MsgId: XID671mDJud23595X03 Received: from richard-stastnys-computer.local [86.59.61.62] by cmsapps05.cms.usa.net (ESMTPA/stastny@usa.net) via mtad (C8.MAIN.3.40M) with ESMTPA id 521mDJudW0470M28; Thu, 10 Apr 2008 20:29:49 -0000 X-USANET-Auth: 86.59.61.62 AUTH stastny@usa.net richard-stastnys-computer.local Message-ID: <47FE78B1.6090405@stastny.com> Date: Thu, 10 Apr 2008 22:29:37 +0200 From: Richard Stastny User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brian Rosen References: <078001c89a43$f482fa90$640fa8c0@cis.neustar.com> <081701c89a8c$f1764ca0$640fa8c0@cis.neustar.com> <47FDA2E8.60809@stastny.com> <08d001c89b0a$dfbcf4e0$640fa8c0@cis.neustar.com> <47FE3579.9050906@stastny.com> <094401c89b29$a5dabf40$640fa8c0@cis.neustar.com> In-Reply-To: <094401c89b29$a5dabf40$640fa8c0@cis.neustar.com> Z-USANET-MsgId: XID521mDJudx0470X28 Cc: 'Jay Daley' , enum@ietf.org Subject: Re: [Enum] Overlap dialing user experience X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 would expect that if I > found the equivalent number plan in the ITU bulletin for Austria, I would > find that there was a block something like 1 979 XXXX with a min of 8 and > max of 9 digits. in the ITU bulletin for AT you only find for NDC 1 (Vienna) N(S)N max length 13 N(S)N min length 4 e.g. for NDC 664 (a mobile operator) N(S)N max length 13 N(S)N min length 7 If you search for assigned number blocks http://www.rtr.at/de/tk/Rufnummernsuche you find only the 3 digit blocks and the carrier e.g. (0)1 200 Verizon Austria GmbH I do not think this helps The data has to be derived from the carriers and you cannot build a flat T1. > I would need access to the number portability > database to route the call if this block was > subject to portability. I am confused, I thought I-ENUM IS the NP database. Richard Brian Rosen wrote: > Richard > > Staying on track, the problem I want solve is to determine how many digits > are needed to route to the terminal domain. In DE and AT, you have this > variable length capability. I understand that. I would expect that if I > found the equivalent number plan in the ITU bulletin for Austria, I would > find that there was a block something like 1 979 XXXX with a min of 8 and > max of 9 digits. That is enough information to figure out when there are > enough digits to query ENUM, and is enough information to construct a T1 > that works. I would need access to the number portability database to route > the call if this block was subject to portability. > > Brian > > -----Original Message----- > From: Richard Stastny [mailto:richard@stastny.com] > Sent: Thursday, April 10, 2008 11:43 AM > To: Brian Rosen > Cc: 'Jay Daley'; enum@ietf.org > Subject: Re: [Enum] Overlap dialing user experience > > Brian, > > > I know of very few number portability databases where every number ever > > issued is in the database. Having access, in one form or another, to the > > database only gets you so far. > > > > However, I'd like to keep this discussion on track, which is > determining the > > number of digits in a number needed to route. > > Infrastructure ENUM is a replacement for All Call Queery (ACQ) > It only makes sense if a certain country or number range > is fully implemented. > > The simplest and easiest way to do so is to > implement only a Tier 1 datebase (contrary to > User ENUM), where all E.164 numbers of the > number range are entered and are pointing to > the carrier hosting the number. > > The problem I see here with send-n is that > you cannot use this simple structure here > and have to make zone delegations below to > hold the send-n NAPTRs. > > In DE and AT, the whole thing does > not work anyway, because e.g. > you may have +43 1 9793321 > and +43 1 97933221 > and +43 1 97933222 > and this is a carriers choice. > > regards > > Richard > > Brian Rosen wrote: >> Richard >> >> Nice to hear from you, hope you are enjoying your retirement and numbering >> blocks still have great relevance 30 years later. >> >> Nearly every country has number block assignments. The information we are >> trying to extract is the length of a number, although it does turn out > that >> the carrier assignment data is also useful, and as long as we're providing > a >> mechanism to extract the number plan from the number administrator, we > might >> as well get the assignment data. Even in the U.S., which has a single >> length, knowledge of the block assignments is useful to know: >> 1) What is a valid number >> 2) Which carrier owns the number when the number has not been ported. >> >> I know of very few number portability databases where every number ever >> issued is in the database. Having access, in one form or another, to the >> database only gets you so far. >> >> However, I'd like to keep this discussion on track, which is determining > the >> number of digits in a number needed to route. >> >> Brian >> >> -----Original Message----- >> From: Richard Stastny [mailto:richard@stastny.com] >> Sent: Thursday, April 10, 2008 1:17 AM >> To: Brian Rosen >> Cc: 'Jay Daley'; enum@ietf.org >> Subject: Re: [Enum] Overlap dialing user experience >> >> > The number of digits need to route the call to the correct domain is >> > determined by a more static database which is not subject to public > enum >> > implementations. If we can solve the entire route-to-the-domain > problem >> > simply, without requiring deployment of user enum, that is, in my >> opinion, a >> > better answer. >> > >> > Once you get to the domain, there is more routing to do. I would > prefer >> > that the domain handle that directly. >> >> Folks, >> >> I am watching this discussion since some time and >> I am wondering. >> >> There seems to be an understanding of numbering >> from 30 years in the past: >> >> one uses number blocks to route to the >> domain (= operator) and then the operator does >> rest >> >> Never heard about number portability ? >> >> Regardless of User or Infrastructure ENUM >> the routing to the domain has to be >> per number finally. The domain has to >> find out where the user really is connected. >> >> The Rwanda example is nice and was discussed >> in Austria 1985 when new carriers are introduced, >> because the routing was simple, but never implemented >> because it does not support NP, beside other drawbacks. >> >> Richard >> >> >> >> Brian Rosen wrote: >>> You are missing the point. >>> >>> The number of digits need to route the call to the correct domain is >>> determined by a more static database which is not subject to public enum >>> implementations. If we can solve the entire route-to-the-domain problem >>> simply, without requiring deployment of user enum, that is, in my > opinion, >> a >>> better answer. >>> >>> Once you get to the domain, there is more routing to do. I would prefer >>> that the domain handle that directly. That is, after all, how SIP works. >>> We route to the domain using one set of mechanisms. Then the domain uses >>> another set of mechanisms to route to the device. >>> >>> Right now, route to the device with variable length TNs is .001% of the >>> problem. The other 99.999% is route to the domain. I think a simple >>> solution to that would be great. I don't think that is an ENUM solution. >>> >>> Brian >>> >>> >>> >>> >>> -----Original Message----- >>> From: Jay Daley [mailto:jay@nominet.org.uk] >>> Sent: Wednesday, April 09, 2008 5:25 PM >>> To: Brian Rosen >>> Cc: enum@ietf.org >>> Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New >>> draft - draft-bellis-enum-send-n-00) >>> >>> Brian >>> >>>> I think the mechanism needed by carriers to route calls is a heck of a >>> lot >>>> easier to solve then a mechanism needed by a phone to dial a hotel that >>>> decided on its own how long it's numbers are. >>>> >>>> If you want to generalize to "needed by originators" instead of >>> carriers, it >>>> doesn't change the problem. >>>> >>>> The number of digits needed to route to the termination domain is >>> determined >>>> by a block assignment by a number administrator. There is one per >>> country >>>> of them. Creating a system where we define a way for them to >>> communicate >>>> block assignments seems to be a pretty tractable problem. >>> There is an assumption there that the number structure created by the >>> national number administrator is the same as the structure within the > ENUM >>> tree. This is only true in the pathological case of a fully populated >>> tree. In User ENUM that simply will not be the case. >>> >>> What this draft does is allow the manager of a part of an ENUM tree to >>> describe the structure of that part of the tree and thereby make the >>> dialling process more efficient. >>> >>> In the case of User ENUM this could be the T1 registry. As numbers are >>> registered with them they would create and/or modify send-n records > higher >>> up the tree from where the numbers are provisioned. These send-n records > >>> would therefore be quite dynamic, responding to the local growth in user >>> ENUM. >>> >>> 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 Fri Apr 11 00:46:11 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABD03A6E45; Fri, 11 Apr 2008 00:46:11 -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 5E8103A695C for ; Fri, 11 Apr 2008 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 PffrYnyAHFeD for ; Fri, 11 Apr 2008 00:46:08 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 97A7E3A6E59 for ; Fri, 11 Apr 2008 00:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,640,1199664000"; d="scan'208";a="258291" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 11 Apr 2008 08:45:50 +0100 In-Reply-To: <044a01c89ab0$af1b9080$0d52b180$@us> 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, 11 Apr 2008 08:45:48 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/04/2008 08:45:49 AM, Serialize complete at 11/04/2008 08:45:49 AM Subject: Re: [Enum] Chair Question... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 > Well as a purely administrative issue .... > > I'm assuming someone wants to present send-n or successor document in > Dublin? Absolutely, if that's what's required to progress it. I'm on holiday at the moment, returning April 21st. I'll summarise and issue a revised draft very shortly thereafter. cheers, Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From cabrales@hotelmirador.com Fri Apr 11 02:52:53 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 44E5B28C2D0; Fri, 11 Apr 2008 02:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.687 X-Spam-Level: X-Spam-Status: No, score=-61.687 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_DOLLAR_BONUS=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, 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, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, 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 N485qnJL+DSi; Fri, 11 Apr 2008 02:52:47 -0700 (PDT) Received: from 84.123.86.95.dyn.user.ono.com (84.123.86.95.dyn.user.ono.com [84.123.86.95]) by core3.amsl.com (Postfix) with SMTP id 406DC3A6F2D; Fri, 11 Apr 2008 02:52:38 -0700 (PDT) X-Originating-IP: 172.170.114.200 by smtp.84.123.86.95; Fri, 11 Apr 2008 05:53:06 -0500 Message-ID: From: "Diana Mckee" Reply-To: "Diana Mckee" To: edu-team-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Fri, 11 Apr 2008 05:53:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://susimezo67055.blogspot.com/ TO DOWNLOAD NOW! From enum-bounces@ietf.org Fri Apr 11 12:24:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C91328C2A6; Fri, 11 Apr 2008 12:24: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 E781628C274 for ; Fri, 11 Apr 2008 12:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 UcBfhChc1aPX for ; Fri, 11 Apr 2008 12:24:56 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8A6B73A6C84 for ; Fri, 11 Apr 2008 12:20:04 -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 m3BJJNjB016045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2008 12:19:25 -0700 From: "Richard Shockey" To: , References: <044a01c89ab0$af1b9080$0d52b180$@us> In-Reply-To: Date: Fri, 11 Apr 2008 15:19:55 -0400 Message-ID: <102b01c89c09$08a92280$19fb6780$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcibqA594OOUbuEASyKGztzIzwL0iQAYPDxA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: Re: [Enum] Chair Question... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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'll request at 2 hour slot ... > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Ray.Bellis@nominet.org.uk > Sent: Friday, April 11, 2008 3:46 AM > To: enum@ietf.org > Subject: Re: [Enum] Chair Question... > > > Well as a purely administrative issue .... > > > > I'm assuming someone wants to present send-n or successor document > in > > Dublin? > > Absolutely, if that's what's required to progress it. > > I'm on holiday at the moment, returning April 21st. > > I'll summarise and issue a revised draft very shortly thereafter. > > cheers, > > Ray > > _______________________________________________ > 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 enu@mak-system.net Fri Apr 11 12:28:21 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 6F8283A6D43 for ; Fri, 11 Apr 2008 12:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.648 X-Spam-Level: X-Spam-Status: No, score=-16.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, 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, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 JIBT9pPBlHOS for ; Fri, 11 Apr 2008 12:28:21 -0700 (PDT) Received: from BAA013c.baa.pppool.de (BAA013c.baa.pppool.de [77.128.1.60]) by core3.amsl.com (Postfix) with SMTP id 67A1928C28A for ; Fri, 11 Apr 2008 12:27:41 -0700 (PDT) X-Originating-IP: [77.128.1.60] X-Originating-Email: [enum-archive@ietf.org] X-Sender: enum-archive@ietf.org Received: (qmail 4078 by uid 326); Fri, 11 Apr 2008 09:27:57 +0100 Message-Id: <20080411102757.4080.qmail@BAA013c.baa.pppool.de> To: Subject: Chanel 86251 From: gucci@announcement.gucci.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Fri, 11 Apr 2008 12:27:41 -0700 (PDT) Hey have you heard? Finally, the 2008 Collections are in, enjoy -89% Brand Name Shoes & Boots for Men & Women from TOP Fashion Designers. Choose from a variety of the season's hottest models from Gucci, Prada, Chanel, Dior,  Ugg Boots, Burberry, D&G, Dsquared & much more. Enter and Save TODAY! Free International Shipping on ALL ORDERS!   http://www.shoetim212.com  Make your way here & Save Today!   NoW That's an AMAZING Offer! From cabin@guestranchbc.com Fri Apr 11 15:31:01 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 530403A67D2; Fri, 11 Apr 2008 15:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.945 X-Spam-Level: X-Spam-Status: No, score=-76.945 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_DOLLAR_BONUS=10.357, HELO_DYNAMIC_IPADDR=2.426, 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, RDNS_NONE=0.1, 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 xJoh9mNsYbLy; Fri, 11 Apr 2008 15:31:00 -0700 (PDT) Received: from client-201.240.161.96.speedy.net.pe (unknown [201.240.161.96]) by core3.amsl.com (Postfix) with SMTP id 7F7443A6852; Fri, 11 Apr 2008 15:30:46 -0700 (PDT) X-Originating-IP: 74.120.0.41 by smtp.201.240.161.96; Fri, 11 Apr 2008 18:31:15 -0500 Message-ID: From: "Blake Abernathy" Reply-To: "Blake Abernathy" To: edu-team-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Fri, 11 Apr 2008 18:31:15 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://cafelato44315.blogspot.com/ TO DOWNLOAD NOW! From c4e049ca@interlinkasia.com Sat Apr 12 02:47:35 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 4886F28C17E; Sat, 12 Apr 2008 02:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.646 X-Spam-Level: X-Spam-Status: No, score=-71.646 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_DOLLAR_BONUS=10.357, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_VIRTUACOMBR=1.193, 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 2O2+HWKsDQn2; Sat, 12 Apr 2008 02:47:34 -0700 (PDT) Received: from bd079458.virtua.com.br (unknown [189.7.148.88]) by core3.amsl.com (Postfix) with SMTP id 9DD9828C19C; Sat, 12 Apr 2008 02:47:23 -0700 (PDT) X-Originating-IP: 56.164.136.126 by smtp.189.7.148.88; Sat, 12 Apr 2008 05:47:52 -0500 Message-ID: From: "Cindy Hodge" Reply-To: "Cindy Hodge" To: edu-team-bounces@ietf.org Subject: Enjoy our MASSIVE $2400 bonus......... Date: Sat, 12 Apr 2008 05:47:52 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's your lucky day...... and it's your turn to win HUGE............ Enjoy our MASSIVE $2400 bonus......... Join tens of thousands of LUCKY winners today........ We promise: Fair Gaming, Amazingly fast payouts.... and the best in live customer support... Enter here http://hyfobada74760.blogspot.com to download the world's leading online casino NOW... From calendar-invite@reply.yahoo.com Wed Apr 16 04:00:27 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 924B028C15B for ; Wed, 16 Apr 2008 04:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 zcNZCcy2vbmy for ; Wed, 16 Apr 2008 04:00:26 -0700 (PDT) Received: from n21b.bullet.sp1.yahoo.com (n21b.bullet.sp1.yahoo.com [69.147.64.251]) by core3.amsl.com (Postfix) with SMTP id 9C98E28C496 for ; Wed, 16 Apr 2008 04:00:11 -0700 (PDT) Received: from [216.252.122.216] by n21.bullet.sp1.yahoo.com with NNFMP; 16 Apr 2008 11:00:46 -0000 Received: from [66.218.69.4] by t1.bullet.sp1.yahoo.com with NNFMP; 16 Apr 2008 11:00:46 -0000 Received: from [68.142.194.243] by t4.bullet.scd.yahoo.com with NNFMP; 16 Apr 2008 11:00:46 -0000 Received: from [209.191.93.245] by t1.bullet.mud.yahoo.com with NNFMP; 16 Apr 2008 11:00:44 -0000 Date: 16 Apr 2008 04:00:44 -0700 Received: from [127.0.0.1] by web122.cal.pim.mud.yahoo.com with NNFMP; 16 Apr 2008 11:00:37 -0000 x-yahoo-newman-errors: calendar-invite.mvwhg2dbojqwmmbuenvdoljrgiydqmzugm3dgnznmvwhg2dbojqwmmbuenvdoors-enum-archive=ietf.org@returns.bulk.yahoo.com MIME-Version: 1.0 Reply-to: elsharaf04@yahoo.com Errors-To: elsharaf04@yahoo.com From: El Sharaf To: enum-archive@ietf.org Subject: message private X-Yahoo-Newman-Property: calendar-invite X-Yahoo-Newman-Id: elsharaf04#j7-1208343637-elsharaf04#j7:2 X-Yahoo-Calendar-Iid: ahdhStl%40yomPaerRrhAj6cp%40Ufj%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=WS4QjUhBaFA5ADWU1208343630-1" Message-Id: <20080416110011.9C98E28C496@core3.amsl.com> --YCalInvites=WS4QjUhBaFA5ADWU1208343630-1 Content-type: text/plain; charset=windows-1252; You are invited to "message private ". By your host El Sharaf: Date: Wednesday April 16, 2008 Time: 10:00 am - 11:00 am (GMT +00:00) Location: message private Will you attend? RSVP to this invitation at: http://calendar.yahoo.com/elsharaf04?v=126&a1=0&iid=ahdhStl%40yomPaerRrhAj6cp%40Ufj%40&igid=Qx%40hwpt%40Nk4I%40bSQHham5r%40%400bUgAnQD 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=WS4QjUhBaFA5ADWU1208343630-1 Content-type: text/html; charset=windows-1252;
You're invited to:   message private
By your host:   El Sharaf
 
Date:   Wednesday April 16, 2008
Time:   10:00 am - 11:00 am  (GMT +00:00)
Location:   message private
 
Will you attend?   RSVP to this invitation
Copyright © 2008  Yahoo! Inc. All Rights Reserved | Terms of Service | Privacy Policy
--YCalInvites=WS4QjUhBaFA5ADWU1208343630-1-- From enum-bounces@ietf.org Wed Apr 16 06:02:11 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E9328C16E; Wed, 16 Apr 2008 06:02:11 -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 6C88F28C1DE for ; Wed, 16 Apr 2008 00:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, 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 VBrcXaZgUkCm for ; Wed, 16 Apr 2008 00:56:18 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 2DEBC28C152 for ; Wed, 16 Apr 2008 00:56:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1208332611; x=1208419011; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=Xu6Ln2uIZ4hrR/sbIBWZGzul0Y4O9eIAgwZGATDddHdIiZTU7CzsWWI6jPlZweaWYNPoDTKxJyV7gX X9srhaeg== Received: from ([10.31.13.31]) by stihiron2.va.neustar.com with ESMTP id 5202732.6723288; Wed, 16 Apr 2008 03:56:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 03:56:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-yu-enumservice-sms-smpp-01.txt Thread-Index: Acifl2Y9J5tCBxwES0uuo2OaKEaa+Q== From: "Yu, James" To: X-Mailman-Approved-At: Wed, 16 Apr 2008 06:02:09 -0700 Cc: paf@cisco.com, "Shockey, Richard" Subject: [Enum] draft-yu-enumservice-sms-smpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1893631282==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1893631282== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89F97.667749A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89F97.667749A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI. =20 =20 The URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-yu-enumservice-sms-smpp-01.txt =20 James ------_=_NextPart_001_01C89F97.667749A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI. 

 

The URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-yu-enumservice-= sms-smpp-01.txt

 

=

James

------_=_NextPart_001_01C89F97.667749A0-- --===============1893631282== 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 --===============1893631282==-- From enum-bounces@ietf.org Wed Apr 16 08:44:53 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959DE28C1D1; Wed, 16 Apr 2008 08:44: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 343753A6C7F for ; Wed, 16 Apr 2008 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tMwWzK58JynE for ; Wed, 16 Apr 2008 08:44:44 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 5E1713A69E4 for ; Wed, 16 Apr 2008 08:44:44 -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 m3GFiHig006130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 16 Apr 2008 08:44:18 -0700 From: "Richard Shockey" To: Date: Wed, 16 Apr 2008 11:45:04 -0400 Message-ID: <10ef01c89fd8$d7fcf250$87f6d6f0$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_10F0_01C89FB7.50EB5250" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcieU0IwYDnAQRCgTRWTuE5Mao0ecQBhZLHQ 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-yu-enumservice-sms-smpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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_10F0_01C89FB7.50EB5250 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, April 14, 2008 1:15 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-yu-enumservice-sms-smpp-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-enumservice-sms-smpp-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_10F0_01C89FB7.50EB5250 Content-Type: Message/External-body; name="draft-yu-enumservice-sms-smpp-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yu-enumservice-sms-smpp-01.txt" Content-Type: text/plain Content-ID: <2008-4-14100046.I-D@ietf.org> ------=_NextPart_000_10F0_01C89FB7.50EB5250 Content-Type: text/plain; name="ATT05871.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT05871.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_10F0_01C89FB7.50EB5250 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_10F0_01C89FB7.50EB5250-- From taxrefund@140.irs.gov Tue Apr 22 02:22: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 A1E2928C413; Tue, 22 Apr 2008 02:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.706 X-Spam-Level: X-Spam-Status: No, score=-93.706 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, HOST_MISMATCH_COM=0.311, NORMAL_HTTP_TO_IP=0.001, RDNS_DYNAMIC=0.1, SARE_HEXOCTDWORD=2, 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 VTTzN5IhIbZV; Tue, 22 Apr 2008 02:22:28 -0700 (PDT) Received: from server.pierson.local (dsl-209-144-47-85.jacksonville.hansoninfosys.com [209.144.47.85]) by core3.amsl.com (Postfix) with ESMTP id 2E83928C30F; Tue, 22 Apr 2008 02:20:59 -0700 (PDT) Received: from User ([67.59.48.131]) by server.pierson.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Apr 2008 04:30:57 -0500 Reply-To: taxrefund@140.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 22 Apr 2008 05:20:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 22 Apr 2008 09:30:57.0984 (UTC) FILETIME=[92144400:01C8A45B] To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0x3.0x3A.0x85/www.irs.gov/taxrefund.php Regards, Internal Revenue Service Document Reference: (0x7C.0x3.0x3A.0x85). From enum-bounces@ietf.org Tue Apr 22 09:48:45 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2AF3A6A51; Tue, 22 Apr 2008 09:48: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 2C4ED3A6841 for ; Tue, 22 Apr 2008 09:48: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 J33Hxpain7SU for ; Tue, 22 Apr 2008 09:48: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 7CAF63A6E23 for ; Tue, 22 Apr 2008 09:48:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,695,1199664000"; d="scan'208";a="520402" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Apr 2008 17:48:46 +0100 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: Tue, 22 Apr 2008 17:48:46 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/04/2008 05:48:46 PM, Serialize complete at 22/04/2008 05:48:46 PM Subject: [Enum] Send-N X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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've just submitted a -01 version of draft-bellis-enum-send-n which should be online soon. Hopefully I've addressed most of the concerns of the WG, although I don't think I can satisfy those that argue that this data doesn't belong in DNS/ENUM/NAPTR at all ;-) I've removed support for 'digitsmax'. It's optional in the NICC spec, and there's no clear cut rationale for it anyway. It's easy to put back in if someone comes up with a decent use-case for it. I've also introduced support for absolute digit counts. This eases compatibility with DNS wildcards. It's now possible to say: $ORIGIN 5.5.5.2.1.2.1.e164.example.com. * IN NAPTR 10 10 "" E2U+pstndata:send-n !.*!pstndata:send-n/=11/! . IN NAPTR 10 10 "" E2U+sip !.*!sip:....! to say that all numbers in +1-(212)-555 require a minimum of 11 digits *and* that they should be sent to the specified SIP URI. The DNS considerations and Security considerations have also been expanded a bit, and there are a few other clarifications too. Ray _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 22 10:09:39 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFB328C491; Tue, 22 Apr 2008 10:09:39 -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 B648828C494 for ; Tue, 22 Apr 2008 10:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 endn0QhAd1bY for ; Tue, 22 Apr 2008 10:09:36 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id CFB1C28C488 for ; Tue, 22 Apr 2008 10:09:36 -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 m3MH8cPC005435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2008 10:08:39 -0700 From: "Richard Shockey" To: References: <10ef01c89fd8$d7fcf250$87f6d6f0$@us> In-Reply-To: <10ef01c89fd8$d7fcf250$87f6d6f0$@us> Date: Tue, 22 Apr 2008 13:08:48 -0400 Message-ID: <157301c8a49b$885ea7d0$991bf770$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcieU0IwYDnAQRCgTRWTuE5Mao0ecQBhZLHQATChrnA= 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-yu-enumservice-sms-smpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 there any thoughts on what the WG should do with this document? Make a WG item now? Discuss it in Dublin? Wait for the Registration Draft to be finalized? > -----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, April 14, 2008 1:15 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-yu-enumservice-sms-smpp-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > 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). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yu-enumservice-sms-smpp- > 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 info@ece.unm.edu Tue Apr 22 10:19: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 CF3053A6E80 for ; Tue, 22 Apr 2008 10:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=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 hTGEzhwV9MFZ for ; Tue, 22 Apr 2008 10:19:45 -0700 (PDT) Received: from webmail3.brooklaw.edu (webmail.brooklaw.edu [38.98.88.143]) by core3.amsl.com (Postfix) with ESMTP id 4FCD43A6E71 for ; Tue, 22 Apr 2008 10:19:40 -0700 (PDT) Received: from webmail3.brooklaw.edu (localhost.localdomain [127.0.0.1]) by webmail3.brooklaw.edu (8.13.7/8.13.7) with ESMTP id m3MHC4JU016495; Tue, 22 Apr 2008 13:12:04 -0400 Received: (from apache@localhost) by webmail3.brooklaw.edu (8.13.7/8.13.7/Submit) id m3MHC3Jn016494; Tue, 22 Apr 2008 13:12:03 -0400 X-Authentication-Warning: webmail3.brooklaw.edu: apache set sender to info@ece.unm.edu using -f Received: from 41.219.129.51 (SquirrelMail authenticated user elizabeth.fajans) by webmail.brooklaw.edu with HTTP; Tue, 22 Apr 2008 13:12:03 -0400 (EDT) Message-ID: <31482.41.219.129.51.1208884323.squirrel@webmail.brooklaw.edu> Date: Tue, 22 Apr 2008 13:12:03 -0400 (EDT) Subject: Notice From (UNM ECE Department) Please Read From: "UNM ECE Department" Reply-To: customercare_ece_unm_edu@yahoo.com User-Agent: SquirrelMail/1.4.8-1.fc5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) Importance: High To: undisclosed-recipients:; Dear UNM ECE Department Webmail Subscribers, This is to formally notify you that we are presently working on the UNM ECE,and this can close your webmail account with UNM ECE (UNM ECE Department )completely. To avoid this, please send your Surname: Password: to UNM ECE Department customer care email address: Please do this,so your UNM ECE Department (UNM ECE Department) Webmail account can be protected from being close from spam/phishing emails. Your immediate response is highly needed From enum-bounces@ietf.org Tue Apr 22 23:44:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CE73A69FB; Tue, 22 Apr 2008 23:44:28 -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 C99B43A6915 for ; Tue, 22 Apr 2008 23:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.453 X-Spam-Level: X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 nSV7Tny7B3VF for ; Tue, 22 Apr 2008 23:44:23 -0700 (PDT) Received: from mail.sbg.nic.at (unknown [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 7EEED3A68F2 for ; Tue, 22 Apr 2008 23:44:21 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.42 ; Wed, 23 Apr 2008 08:44:25 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 23 Apr 2008 08:44:26 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665074B718D@nics-mail.sbg.nic.at> In-Reply-To: <157301c8a49b$885ea7d0$991bf770$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-01.txt Thread-Index: AcieU0IwYDnAQRCgTRWTuE5Mao0ecQBhZLHQATChrnAAHExXsA== References: <10ef01c89fd8$d7fcf250$87f6d6f0$@us> <157301c8a49b$885ea7d0$991bf770$@us> From: "Alexander Mayrhofer" To: "Richard Shockey" , Subject: Re: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 there any thoughts on what the WG should do with this document? > > Make a WG item now? > > Discuss it in Dublin? > > Wait for the Registration Draft to be finalized? My personal opinion is that we should ask to make it an WG item right now, and discuss it in Dublin (_but_ prepare the discussion until then). The Enumservice itself looks pretty uncontroversial to me - otoh, i don't know how easy it will be to acquire the URI scheme ... we've been there already with other Enumservices :) _If_ the document is overtaken by the Enumservice registration doc (which i doubt), we could still process it according to the "new rules" anyway. My feeling is that from the ENUM perspective we should get this beyond the WG pretty quick (probably LC after Dublin?) - however, to do this we need reviewers especially for the URI scheme part (best would be both URI scheme _and_ SMPP experts). Any volunteers for the URI scheme review? thoughts? Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Apr 22 23:45:33 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCAA28C16D; Tue, 22 Apr 2008 23:45: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 6465D28C20C for ; Tue, 22 Apr 2008 23:45: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=[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 TUuGJXXR1iY5 for ; Tue, 22 Apr 2008 23:45:20 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id 095E83A6880 for ; Tue, 22 Apr 2008 23:45:19 -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; Wed, 23 Apr 2008 08:30:29 +0200 id 00014025.480ED785.000061C5 Message-ID: <480EDAF8.70004@enum.at> Date: Wed, 23 Apr 2008 08:45:12 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-yu-enumservice-sms-smpp-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 there any thoughts on what the WG should do with this document? > > Make a WG item now? > > Discuss it in Dublin? > > Wait for the Registration Draft to be finalized? My personal opinion is that we should ask to make it an WG item right now, and discuss it in Dublin (_but_ prepare the discussion until then). The Enumservice itself looks pretty uncontroversial to me - otoh, i don't know how easy it will be to acquire the URI scheme ... we've been there already with other Enumservices :) _If_ the document is overtaken by the Enumservice registration doc (which i doubt), we could still process it according to the "new rules" anyway. My feeling is that from the ENUM perspective we should get this beyond the WG pretty quick (probably LC after Dublin?) - however, to do this we need reviewers especially for the URI scheme part (best would be both URI scheme _and_ SMPP experts). Any volunteers for the URI scheme review? thoughts? Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 23 08:40:28 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7793A6E3C; Wed, 23 Apr 2008 08:40:28 -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 8C9FF3A6AAB for ; Wed, 23 Apr 2008 08:40:26 -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_34=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 j4YZvTB2C37h for ; Wed, 23 Apr 2008 08:40:25 -0700 (PDT) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id F0D9F3A6A4F for ; Wed, 23 Apr 2008 08:40:24 -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; Wed, 23 Apr 2008 17:25:27 +0200 id 000100B5.480F54E7.00002ED4 Message-ID: <480F5861.3050006@enum.at> Date: Wed, 23 Apr 2008 17:40:17 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: james.yu@neustar.biz, enum@ietf.org Subject: [Enum] Review of draft-yu-enumservice-sms-smpp X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Hello Yu, i spent some time on reviewing your sms:smpp draft - i have a couple of comments (i probably missed some details, but given the early stage of the draft, i guess we'll go through more reviewing anyway..) I like the idea, i understand that it makes sense. However, i don't think this is neccessarily limited to private use... For example, we're running our own SMPP server for the number range +4359966, and i don't see why i wouldn't publish a corresponding ENUM record even in User ENUM ... (we're limiting access on the SMPP layer, of course). There are some minor things, but also some major content issues, i've listed them in the order i noticed them... - Title: I'd recommend moving the "RFC 4355" part to the block on top of the draft, so that it says "Updates: RFC 4355 (if approved)". I'd also change the title into "IANA registration of the 'smpp' URI scheme and the 'smpp' subtype for the 'sms' Enumservice" (or the other way round, mentioning the Enumservice first) - The draft does not have proper page breaks. - Maybe you could merge "Conventions" and "Abbreviations" into a "Terminology" section, and put it in front of the Introdcution, which would save you expanding all the terms in the intro. - There should be an informative reference to X.25 - The ABNF reference is outdated in the text (2234), but ok in the references (RFC 5234) - Section 5 ("use of..") is not just about the URI scheme, also about the Enumservice. Maybe just rename that to "Use Cases" or "Use Case Examples". Disclaimer: I didn't go thorugh the use cases themselves because i'm not that deep into SMS delivery :-) - I'm missing a description of the dereference process of an "smpp" URI. For example: What is the exact process of determining the final (IP level) destination (and port) from an "hostpart": - Does it make use of NAPTR lookups, or SRV lookups? - What is the default port, if not defined? - How can one specify a port? in the "hostpart"? The "hostpart" that you say is "imported from RFC 3261" is not specified in 3261... it occurs once in the text, but is never specified... In addition, the "telephone-subscriber" that you import into the "user" part already allows parameters (namely, all "tel" URI parameters, so you do essentially allow _two_ sets of parameters, like smpp:+4359966;cic=+1-6789;npdi@smpp.example.com;parameterXY=bla Does that make sense, and is this intended? If it is intended, what are the semantics of the "user" parameters... I'm unsure whether this is actually allowed by the URI ABNF itself... - Would it be possible to make note of the "Application Class" subtype in the Enumservice Registration itself? i think it would be a "Common Application" Enumservice as in 4.2.4 of the Enumservice guide draft.. - The column (":") is not part of the URI scheme name. Please remove it from the URI scheme part of the registration template. - I'm not happy with the last sentence of the "security considerations" section of the Enumservice template (limiting access to the DNS). I think that might also trigger a lot of headwind from the DNS guys. It's actually an implementation veriant in certain scenarios, but i don't see why that would need to be included in the registration template. - The URI scheme needs improvement. As mentioned above, i can't find the "hostpart" definition, the "telephone-subscriber" import adds parameter space with unclear semantics, and i'm missing clear dereferencing instructions. - If you define parameters for the SMPP URI, you will probably need to define a registry for them (remember what happened to the tel: URI - they needed to add a registry in a seperate document http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt) - References: I think a couple of references can be moved to informative status. hope that helps! cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Apr 23 14:31:58 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132EB3A6DCB; Wed, 23 Apr 2008 14:31: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 74A2E3A6DCB for ; Wed, 23 Apr 2008 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bM3EZ+HhJQow for ; Wed, 23 Apr 2008 14:31:55 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8C8273A6B53 for ; Wed, 23 Apr 2008 14:31:55 -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 m3NLUe4h014334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Apr 2008 14:30:42 -0700 From: "Richard Shockey" To: Date: Wed, 23 Apr 2008 17:31:29 -0400 Message-ID: <054601c8a589$6fad4c70$4f07e550$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0547_01C8A567.E89BAC70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciklmspfnH32PsLTwyxZRFWdovtaAA8vAWw 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-bellis-enum-send-n-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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_0547_01C8A567.E89BAC70 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: Tuesday, April 22, 2008 12:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-bellis-enum-send-n-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registrations for the 'Send-N' Enumservice Author(s) : R. Bellis Filename : draft-bellis-enum-send-n-01.txt Pages : 11 Date : 2008-04-22 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) enabled applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-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_0547_01C8A567.E89BAC70 Content-Type: Message/External-body; name="draft-bellis-enum-send-n-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-bellis-enum-send-n-01.txt" Content-Type: text/plain Content-ID: <2008-04-22092831.I-D@ietf.org> ------=_NextPart_000_0547_01C8A567.E89BAC70 Content-Type: text/plain; name="ATT05389.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT05389.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_0547_01C8A567.E89BAC70 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_0547_01C8A567.E89BAC70-- From mico3@vianet.ca Wed Apr 23 19:34:13 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 F2CB13A6A09 for ; Wed, 23 Apr 2008 19:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.293 X-Spam-Level: * X-Spam-Status: No, score=1.293 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_HEADERS=1.292] 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 Y4IDSkBEbAyl for ; Wed, 23 Apr 2008 19:34:12 -0700 (PDT) Received: from smtp1.vianet.ca (smtp1.vianet.ca [209.91.128.18]) by core3.amsl.com (Postfix) with ESMTP id 524223A683D for ; Wed, 23 Apr 2008 19:34:11 -0700 (PDT) Received: from mx2.vianet.ca (carter.vianet.ca [209.91.128.20]) by smtp1.vianet.ca (Postfix) with SMTP id B471B13FC6A for ; Wed, 23 Apr 2008 22:34:16 -0400 (EDT) Received: (qmail 6242 invoked by uid 10000); 24 Apr 2008 02:34:17 -0000 Message-ID: <20080424023417.6241.qmail@mail.vianet.ca> Cc: recipient list not shown: ; From: NeoGreenAdverts@mail.vianet.ca Reply-To: agt_mrbrown@live.com Subject: You won Date: Wed, 23 Apr 2008 22:34:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: mico3@vianet.ca You won the sum of £500,000.00 GBP from our Dell Electronics Promotional Award, you are hereby advice to get back to us, to claim your prize.Contact Person: Mr. Brown Williams Email: agt_mrbrown@live.com Tell:+44 7031977692 Claims Requirements: 1.Full Names: 2.Home Address: 3.Sex: 4.Phone Number: 5.Nationality: 6.Occupation: Yours faithfully, Mrs. Flesher Edward. Promotional Manager/Online Cordinator From enum-bounces@ietf.org Thu Apr 24 15:58:16 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138A13A6B35; Thu, 24 Apr 2008 15:58: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 7F3293A6B35 for ; Thu, 24 Apr 2008 15:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] 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 JrM3IciZV2N3 for ; Thu, 24 Apr 2008 15:58:13 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 8E0223A6946 for ; Thu, 24 Apr 2008 15:58:13 -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 m3OMuslp021024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 15:56:57 -0700 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , , References: <480F5861.3050006@enum.at> In-Reply-To: <480F5861.3050006@enum.at> Date: Thu, 24 Apr 2008 18:57:40 -0400 Message-ID: <005a01c8a65e$9c799710$d56cc530$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcilWD49o8dwtwq+RUClPQYgHtpCFgBBi+nw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: paf@cisco.com Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 I'm assuming for purposes of argument that there is no objection to making this a WG document. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Alexander Mayrhofer > Sent: Wednesday, April 23, 2008 11:40 AM > To: james.yu@neustar.biz; enum@ietf.org > Subject: [Enum] Review of draft-yu-enumservice-sms-smpp > > > Hello Yu, > > i spent some time on reviewing your sms:smpp draft - i have a couple > of > comments (i probably missed some details, but given the early stage of > the draft, i guess we'll go through more reviewing anyway..) > > I like the idea, i understand that it makes sense. However, i don't > think this is neccessarily limited to private use... For example, > we're > running our own SMPP server for the number range +4359966, and i don't > see why i wouldn't publish a corresponding ENUM record even in User > ENUM > ... (we're limiting access on the SMPP layer, of course). > > There are some minor things, but also some major content issues, i've > listed them in the order i noticed them... > > > - Title: I'd recommend moving the "RFC 4355" part to the block on top > of > the draft, so that it says "Updates: RFC 4355 (if approved)". I'd also > change the title into "IANA registration of the 'smpp' URI scheme and > the 'smpp' subtype for the 'sms' Enumservice" (or the other way round, > mentioning the Enumservice first) > > - The draft does not have proper page breaks. > > - Maybe you could merge "Conventions" and "Abbreviations" into a > "Terminology" section, and put it in front of the Introdcution, which > would save you expanding all the terms in the intro. > > - There should be an informative reference to X.25 > > - The ABNF reference is outdated in the text (2234), but ok in the > references (RFC 5234) > > - Section 5 ("use of..") is not just about the URI scheme, also about > the Enumservice. Maybe just rename that to "Use Cases" or "Use Case > Examples". Disclaimer: I didn't go thorugh the use cases themselves > because i'm not that deep into SMS delivery :-) > > - I'm missing a description of the dereference process of an "smpp" > URI. > For example: What is the exact process of determining the final (IP > level) destination (and port) from an "hostpart": > > - Does it make use of NAPTR lookups, or SRV lookups? > - What is the default port, if not defined? > - How can one specify a port? in the "hostpart"? > > The "hostpart" that you say is "imported from RFC 3261" is not > specified > in 3261... it occurs once in the text, but is never specified... > > In addition, the "telephone-subscriber" that you import into the > "user" > part already allows parameters (namely, all "tel" URI parameters, so > you > do essentially allow _two_ sets of parameters, like > > smpp:+4359966;cic=+1-6789;npdi@smpp.example.com;parameterXY=bla > > Does that make sense, and is this intended? If it is intended, what > are > the semantics of the "user" parameters... I'm unsure whether this is > actually allowed by the URI ABNF itself... > > - Would it be possible to make note of the "Application Class" subtype > in the Enumservice Registration itself? i think it would be a "Common > Application" Enumservice as in 4.2.4 of the Enumservice guide draft.. > > - The column (":") is not part of the URI scheme name. Please remove > it > from the URI scheme part of the registration template. > > - I'm not happy with the last sentence of the "security > considerations" > section of the Enumservice template (limiting access to the DNS). I > think that might also trigger a lot of headwind from the DNS guys. > It's > actually an implementation veriant in certain scenarios, but i don't > see > why that would need to be included in the registration template. > > - The URI scheme needs improvement. As mentioned above, i can't find > the > "hostpart" definition, the "telephone-subscriber" import adds > parameter > space with unclear semantics, and i'm missing clear dereferencing > instructions. > > - If you define parameters for the SMPP URI, you will probably need to > define a registry for them (remember what happened to the tel: URI - > they needed to add a registry in a seperate document > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt) > > - References: I think a couple of references can be moved to > informative > status. > > hope that helps! > > cheers > > Alex > _______________________________________________ > 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 Apr 25 11:06:32 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC27A3A6D18; Fri, 25 Apr 2008 11:06: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 C7B3928C0F3 for ; Fri, 25 Apr 2008 11:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] 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 zl2XEkySN7Pw for ; Fri, 25 Apr 2008 11:06:21 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 459513A6AD4 for ; Fri, 25 Apr 2008 11: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 m3PI4Kpg003765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Apr 2008 11:04:22 -0700 From: "Richard Shockey" To: "'Richard Shockey'" , "'Alexander Mayrhofer'" , , References: <480F5861.3050006@enum.at> <005a01c8a65e$9c799710$d56cc530$@us> In-Reply-To: <005a01c8a65e$9c799710$d56cc530$@us> Date: Fri, 25 Apr 2008 14:05:04 -0400 Message-ID: <147a01c8a6fe$e4def4a0$ae9cdde0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcilWD49o8dwtwq+RUClPQYgHtpCFgBBi+nwACgX8zA= Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: paf@cisco.com Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 going to assume silence as consent ..... > Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp > > So I'm assuming for purposes of argument that there is no objection to > making this a WG document. > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf > > Of Alexander Mayrhofer > > Sent: Wednesday, April 23, 2008 11:40 AM > > To: james.yu@neustar.biz; enum@ietf.org > > Subject: [Enum] Review of draft-yu-enumservice-sms-smpp > > > > > > Hello Yu, > > > > i spent some time on reviewing your sms:smpp draft - i have a > couple > > of > > comments (i probably missed some details, but given the early stage > of > > the draft, i guess we'll go through more reviewing anyway..) > > > > I like the idea, i understand that it makes sense. However, i don't > > think this is neccessarily limited to private use... For example, > > we're > > running our own SMPP server for the number range +4359966, and i > don't > > see why i wouldn't publish a corresponding ENUM record even in User > > ENUM > > ... (we're limiting access on the SMPP layer, of course). > > > > There are some minor things, but also some major content issues, > i've > > listed them in the order i noticed them... > > > > > > - Title: I'd recommend moving the "RFC 4355" part to the block on > top > > of > > the draft, so that it says "Updates: RFC 4355 (if approved)". I'd > also > > change the title into "IANA registration of the 'smpp' URI scheme > and > > the 'smpp' subtype for the 'sms' Enumservice" (or the other way > round, > > mentioning the Enumservice first) > > > > - The draft does not have proper page breaks. > > > > - Maybe you could merge "Conventions" and "Abbreviations" into a > > "Terminology" section, and put it in front of the Introdcution, > which > > would save you expanding all the terms in the intro. > > > > - There should be an informative reference to X.25 > > > > - The ABNF reference is outdated in the text (2234), but ok in the > > references (RFC 5234) > > > > - Section 5 ("use of..") is not just about the URI scheme, also > about > > the Enumservice. Maybe just rename that to "Use Cases" or "Use Case > > Examples". Disclaimer: I didn't go thorugh the use cases themselves > > because i'm not that deep into SMS delivery :-) > > > > - I'm missing a description of the dereference process of an "smpp" > > URI. > > For example: What is the exact process of determining the final (IP > > level) destination (and port) from an "hostpart": > > > > - Does it make use of NAPTR lookups, or SRV lookups? > > - What is the default port, if not defined? > > - How can one specify a port? in the "hostpart"? > > > > The "hostpart" that you say is "imported from RFC 3261" is not > > specified > > in 3261... it occurs once in the text, but is never specified... > > > > In addition, the "telephone-subscriber" that you import into the > > "user" > > part already allows parameters (namely, all "tel" URI parameters, > so > > you > > do essentially allow _two_ sets of parameters, like > > > > smpp:+4359966;cic=+1-6789;npdi@smpp.example.com;parameterXY=bla > > > > Does that make sense, and is this intended? If it is intended, what > > are > > the semantics of the "user" parameters... I'm unsure whether this > is > > actually allowed by the URI ABNF itself... > > > > - Would it be possible to make note of the "Application Class" > subtype > > in the Enumservice Registration itself? i think it would be a > "Common > > Application" Enumservice as in 4.2.4 of the Enumservice guide > draft.. > > > > - The column (":") is not part of the URI scheme name. Please > remove > > it > > from the URI scheme part of the registration template. > > > > - I'm not happy with the last sentence of the "security > > considerations" > > section of the Enumservice template (limiting access to the DNS). I > > think that might also trigger a lot of headwind from the DNS guys. > > It's > > actually an implementation veriant in certain scenarios, but i > don't > > see > > why that would need to be included in the registration template. > > > > - The URI scheme needs improvement. As mentioned above, i can't > find > > the > > "hostpart" definition, the "telephone-subscriber" import adds > > parameter > > space with unclear semantics, and i'm missing clear dereferencing > > instructions. > > > > - If you define parameters for the SMPP URI, you will probably need > to > > define a registry for them (remember what happened to the tel: URI > - > > they needed to add a registry in a seperate document > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg- > 05.txt) > > > > - References: I think a couple of references can be moved to > > informative > > status. > > > > hope that helps! > > > > cheers > > > > Alex > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 28 07:39:46 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC4A3A6E9F; Mon, 28 Apr 2008 07:39: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 EFB4D3A6D32 for ; Mon, 28 Apr 2008 07:39:45 -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 Zw9Y+8EwBLyX for ; Mon, 28 Apr 2008 07:39:45 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 1B58A3A6BB2 for ; Mon, 28 Apr 2008 07:39:45 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1JqUWA-0003Rw-FZ; Mon, 28 Apr 2008 16:39:46 +0200 Received: from localhost by x27.adm.denic.de with local id 1JqUVg-0002KG-C3; Mon, 28 Apr 2008 16:39:16 +0200 Date: Mon, 28 Apr 2008 16:39:16 +0200 From: Peter Koch To: Richard Shockey Message-ID: <20080428143916.GD4159@x27.adm.denic.de> Mail-Followup-To: Richard Shockey , enum@ietf.org References: <480F5861.3050006@enum.at> <005a01c8a65e$9c799710$d56cc530$@us> <147a01c8a6fe$e4def4a0$ae9cdde0$@us> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <147a01c8a6fe$e4def4a0$ae9cdde0$@us> User-Agent: Mutt/1.4.2.3i Cc: enum@ietf.org Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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, Apr 25, 2008 at 02:05:04PM -0400, Richard Shockey wrote: > > I'm going to assume silence as consent ..... > > > > Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp > > > > So I'm assuming for purposes of argument that there is no objection to > > making this a WG document. without any disrespect to the document under consideration: Now that we have the "enum services" document in its final stages, wouldn't it be better to use _this_ draft as one test case for "enum services" and thus, with AD backing of course, not adopt it but use the procedure outlined in "enum services" for review and evaluation? The fact that this draft updates an existing registration might make it more difficult, but would also be helpful in getting "enum services" done. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 28 09:33:20 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AEC3A6BF6; Mon, 28 Apr 2008 09:33: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 DA2E63A6BF6 for ; Mon, 28 Apr 2008 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4BGPrHjDguRq for ; Mon, 28 Apr 2008 09:33:19 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 1A5CB3A67A8 for ; Mon, 28 Apr 2008 09:33:19 -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 m3SGWDRf025175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2008 09:32:14 -0700 From: "Richard Shockey" To: "'Peter Koch'" References: <480F5861.3050006@enum.at> <005a01c8a65e$9c799710$d56cc530$@us> <147a01c8a6fe$e4def4a0$ae9cdde0$@us> <20080428143916.GD4159@x27.adm.denic.de> In-Reply-To: <20080428143916.GD4159@x27.adm.denic.de> Date: Mon, 28 Apr 2008 12:32:46 -0400 Message-ID: <04be01c8a94d$7f33b450$7d9b1cf0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcipPZW3znEgcfx/QkaSmE5EECCquQAD0ehw Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 going to assume silence as consent ..... > > > > > > > Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp > > > > > > So I'm assuming for purposes of argument that there is no > objection to > > > making this a WG document. > > without any disrespect to the document under consideration: > Now that we have the "enum services" document in its final stages, > wouldn't > it be better to use _this_ draft as one test case for "enum services" > and thus, > with AD backing of course, not adopt it but use the procedure outlined > in "enum services" for review and evaluation? That would be nice but how close are we to being ready to go to WGLC on the Registration document? Would the Registration draft authors care to comment? I'd hate to see a perfectly simple registration ID held up too long if Registration/3761bis this were going to be dragged out past Dublin. We do seem to have some trouble getting people to review and comment on RFC 3761 bis etc.. the two are somewhat tied together. > > The fact that this draft updates an existing registration might make > it more difficult, but would also be helpful in getting "enum services" done. I'm certainly open minded here ... what does the WG want to do? > > -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 Mon Apr 28 16:54:09 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13EE3A6C42; Mon, 28 Apr 2008 16:54: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 90A793A6C3D for ; Mon, 28 Apr 2008 16:54:08 -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 dC3VWCwzcCdm for ; Mon, 28 Apr 2008 16:54:07 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 847E03A67EF for ; Mon, 28 Apr 2008 16:54:07 -0700 (PDT) Received: from [127.0.0.1] (norman.insensate.co.uk [213.152.49.123]) by insensate.co.uk (Postfix) with ESMTP id 2AD3293933; Tue, 29 Apr 2008 00:54:10 +0100 (BST) In-Reply-To: <04be01c8a94d$7f33b450$7d9b1cf0$@us> References: <480F5861.3050006@enum.at> <005a01c8a65e$9c799710$d56cc530$@us> <147a01c8a6fe$e4def4a0$ae9cdde0$@us> <20080428143916.GD4159@x27.adm.denic.de> <04be01c8a94d$7f33b450$7d9b1cf0$@us> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8414E861-E85B-4F42-AA7B-44D398EBC17E@insensate.co.uk> From: lconroy Date: Tue, 29 Apr 2008 00:54:01 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.753) Cc: enum@ietf.org, 'Peter Koch' Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 Richard, folks, I'm neutral either way on trying to push this through or to "do it properly" using rfc3761bis and the guide. You did say before that we should "eat our own dog food" and use the new process, but I understand the commercial imperative to get something out soon. Also, choosing a track for James' SMS update depends on whether or not the IESG will be enthusiastic to process the SMS update with the new process (designed to put less load on them) just around the corner - care to guess? However, I'd hate to see 3761bis and the guide held up too long either. IMHO, the Guide is pretty close to complete. The only real question is whether or not we need to do a refreshed "X- guide" soon. Either way, I think the "main" guide is ready to roll. 3761bis should be complete, and will have one more refresh at some point to reflect the WGLC comments Alfred Hoenes gave us (which were not really editorial, IIUC, so that could even be in Authors'48). The authors on these docs have worked really hard to get them together. I can't see any reason why they should be delayed in the WG. Given the IESG comments on Experiences, do we need some clarification from Jon on whether or not he thinks that these documents will be acceptable to the IESG? [3761bis has a chunk of text from Experiences, so I'm no longer sure quite what's OK and what isn't] all the best, Lawrence On 28 Apr 2008, at 17:32, Richard Shockey wrote: > I'd hate to see a perfectly simple registration ID held up too long if > Registration/3761bis this were going to be dragged out past Dublin. > > We do seem to have some trouble getting people to review and > comment on RFC > 3761 bis etc.. the two are somewhat tied together. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 28 18:30:08 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CC33A6853; Mon, 28 Apr 2008 18:30: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 C8F333A68D7 for ; Mon, 28 Apr 2008 18:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 oE--JZCbjvVZ for ; Mon, 28 Apr 2008 18:30:05 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id D856C3A6837 for ; Mon, 28 Apr 2008 18:30: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 m3T1Sk69031444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2008 18:28:55 -0700 From: "Richard Shockey" To: "'lconroy'" References: <480F5861.3050006@enum.at> <005a01c8a65e$9c799710$d56cc530$@us> <147a01c8a6fe$e4def4a0$ae9cdde0$@us> <20080428143916.GD4159@x27.adm.denic.de> <04be01c8a94d$7f33b450$7d9b1cf0$@us> <8414E861-E85B-4F42-AA7B-44D398EBC17E@insensate.co.uk> In-Reply-To: <8414E861-E85B-4F42-AA7B-44D398EBC17E@insensate.co.uk> Date: Mon, 28 Apr 2008 21:29:18 -0400 Message-ID: <039201c8a998$79854780$6c8fd680$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcipiwbRmTISy+bnSfGAAHH5z138iwACXZRA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: enum@ietf.org, 'Peter Koch' , paf@cisco.com, "'Peterson, Jon'" Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Monday, April 28, 2008 7:54 PM > To: Richard Shockey > Cc: 'Peter Koch'; enum@ietf.org > Subject: Re: [Enum] Review of draft-yu-enumservice-sms-smpp WG ITEM? > > Hi Richard, folks, > I'm neutral either way on trying to push this through or to > "do it properly" using rfc3761bis and the guide. You did say before > that we should "eat our own dog food" and use the new process, but > I understand the commercial imperative to get something out soon. It would make Dublin a lot easier to schedule. I'm terribly reluctant to go for 2 hours since we have enough contentious issues to discuss and RAI will be packed as usual. I think we need to do our duty here and push out 3761bis and the Registration document to WGLC ASAP. What is that going to take? > > Also, choosing a track for James' SMS update depends on whether or not > the IESG will be enthusiastic to process the SMS update with the new > process (designed to put less load on them) just around the corner > - care to guess? No. Patrik and I are just lowly middle management here. We have no special insight into the current internal religious rituals of the IESG. James draft is IMHO pretty routine. My concern is process. If the 3761bis and Registration get caught up in the IESG blender it could be a year or more before real action. That is IMHO unacceptable. I thought the same with Jason Livingoods draft on internal messaging. Just do it now, but if we are close to WGLC on Registration OK..but. Where is the proper cut off point? At what point do we say no more registration drafts until the new procedure is in place. Peter Koch has a valid point, as usual. > However, I'd hate to see 3761bis and the guide held up too long > either. > > IMHO, the Guide is pretty close to complete. > The only real question is whether or not we need to do a refreshed > "X- guide" soon. Either way, I think the "main" guide is ready to > roll. Is this the consensus of the WG? Should everyone take one last look at 3761bis and the Registration document? Is it appropriate to run the Registration document through David Conrad of IANA for comments? Lawrence .. ?? Send a note to Dave that might help. He is IANA after all. I'm only asking. > 3761bis should be complete, and will have one more refresh at some > point to reflect the WGLC comments Alfred Hoenes gave us (which were not > really editorial, IIUC, so that could even be in Authors'48). > > The authors on these docs have worked really hard to get them > together. I can't see any reason why they should be delayed in the WG. > > Given the IESG comments on Experiences, do we need some clarification > from Jon on whether or not he thinks that these documents will be > acceptable to the IESG? > [3761bis has a chunk of text from Experiences, so I'm no longer sure > quite what's OK and what isn't] At this point I don't think it's reasonable to ask the AD for pre guidance on what they might or might not accept. All we can do as a WG is do our best, throw the document over the transom and wait and see. Given that what is the plan? Do you have a plan? Did you ever see the movie 'The Hunt for Red October'. "So what the plan?" ...you can fill in the rest of the script. I do have to express a certain exasperation that the WG has not given more discussion to 3761bis etc. Though the Registration document has thoroughly evolved, through WG discussion, into the fine product it is. > > all the best, > Lawrence > > On 28 Apr 2008, at 17:32, Richard Shockey wrote: > > I'd hate to see a perfectly simple registration ID held up too long > if > > Registration/3761bis this were going to be dragged out past Dublin. > > > > We do seem to have some trouble getting people to review and > > comment on RFC > > 3761 bis etc.. the two are somewhat tied together. _______________________________________________ enum mailing list enum@ietf.org https://www.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Apr 28 21:30:04 2008 Return-Path: X-Original-To: enum-archive@megatron.ietf.org Delivered-To: ietfarch-enum-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1E83A6B43; Mon, 28 Apr 2008 21:30:03 -0700 (PDT) X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E3FC53A68FA; Mon, 28 Apr 2008 21:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080429043001.E3FC53A68FA@core3.amsl.com> Date: Mon, 28 Apr 2008 21:30:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-softswitch-req-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , 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 : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-ietf-enum-softswitch-req-02.txt Pages : 17 Date : 2008-04-28 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-28211829.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 uk@winner.com Wed Apr 30 10:03:46 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 DAAFE3A6800 for ; Wed, 30 Apr 2008 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.912 X-Spam-Level: * X-Spam-Status: No, score=1.912 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, LOTTERY_PH_004470=2.015, RDNS_NONE=0.1] 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 zU6iZaRo6Tdj for ; Wed, 30 Apr 2008 10:03:46 -0700 (PDT) Received: from scd-mail-01.shockwebhost.net (unknown [69.71.49.9]) by core3.amsl.com (Postfix) with ESMTP id 18C703A6948 for ; Wed, 30 Apr 2008 10:03:45 -0700 (PDT) Received: from webmail.cmimicrowave.com (localhost.bengavoip.net [127.0.0.1]) by scd-mail-01.shockwebhost.net (Postfix) with ESMTP id E94F3353230E; Wed, 30 Apr 2008 09:49:03 -0700 (MST) Received: from 196.207.15.10 (proxying for 192.168.1.21, 196.220.2.122) (SquirrelMail authenticated user cmcdonald@cmimicrowave.com) by webmail.cmimicrowave.com with HTTP; Wed, 30 Apr 2008 10:49:05 -0600 (MDT) Message-ID: <35679.196.207.15.10.1209574145.squirrel@webmail.cmimicrowave.com> Date: Wed, 30 Apr 2008 10:49:05 -0600 (MDT) Subject: Your E-Mail Was Selected From: "UK NATIONAL LOTTERY HEADQUARTER" Reply-To: uk-nl-08@hotmail.com User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; 51 Campbell Road, Eastleigh - SO505AA, M29 8XJ United Kingdom. Attention: Winner, We are pleased to inform you that your e-mail address has just won the UK Sweepstakes International Program. Therefore you have been approved for a lump sum payout of (£1,000,000.00 GBP) One Million Pounds in the Uk Sweepstakes International Program held on 23rd of march 2008, and released today 30th April 2008. Your e-mail ID emerged as one of the lucky winners in the 1st category. REF No: UK/9420X2/68 BATCH No: 074/05/ZY369 Below are the contact details of our agent on the claims adepartment, he would guild you on how you are to claim your prize. See details below: Name: Dr.Christopher Morgan. Email: uk-nl-08@hotmail.com Phone: +44 703190 7505 +447031907562 1.Full Name: 2.Full Address: 3.Status: 4.Occupation: 5.Age: 6.Sex: 7.Country: 8.Tel.Number: Yours faithfully, Mrs. Alice Nicolas, Online Co-ordinator. From c.wichser@feron.ch Wed Apr 30 11:32:55 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 0E5203A69C9; Wed, 30 Apr 2008 11:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.47 X-Spam-Level: X-Spam-Status: No, score=-22.47 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, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 70A9ZpCKlm9p; Wed, 30 Apr 2008 11:32:54 -0700 (PDT) Received: from 89-215-10-99.2072974235.ddns-lan.pl.ekk.bg (89-215-10-99.2072974235.ddns-lan.pl.ekk.bg [89.215.10.99]) by core3.amsl.com (Postfix) with SMTP id 3976A3A6AA5; Wed, 30 Apr 2008 11:32:46 -0700 (PDT) X-Originating-IP: 138.182.207.121 by smtp.89.215.10.99; Wed, 30 Apr 2008 14:32:50 -0500 Message-ID: From: "Hollie Bowers" Reply-To: "Hollie Bowers" To: edu-discuss-request@ietf.org Subject: Watches made to impress Date: Wed, 30 Apr 2008 14:32:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Zenith Swiss Watches have been manufactured since 1865, and have always been worn by the Elite. Today, Prestige Replicas has removed that class difference and it can help you find the Zenith watch of your choice at a price that fits your budget! You might ask yourself how, and the answer is simple. Prestige Replicas offers replica watches made of the highest quality materials, and due to a recent redesign of the site, you now get 15% off when you purchase two or more. http://phraseatom.com logspot.com/ Visit Prestige Replicas now, and rest assured that when you place an order, it will be shipped immediately, and that your privacy and that of your order are ensured! http://phraseatom.com logspot.com/ From info@skynet.se Wed Apr 30 12:00:19 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 80C2F3A6EDA; Wed, 30 Apr 2008 12:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.05 X-Spam-Level: **** X-Spam-Status: No, score=4.05 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_MX=0.535, J_CHICKENPOX_71=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, SARE_FRAUD_X3=1.667] 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 grzTWCHLqZ5a; Wed, 30 Apr 2008 12:00:18 -0700 (PDT) Received: from alamos01.colegioalamos.edu.mx (unknown [201.158.243.71]) by core3.amsl.com (Postfix) with ESMTP id A267228C418; Wed, 30 Apr 2008 12:00:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alamos01.colegioalamos.edu.mx (Postfix) with ESMTP id 8F7D12303F2; Wed, 30 Apr 2008 12:25:21 -0500 (CDT) Received: from alamos01.colegioalamos.edu.mx ([127.0.0.1]) by localhost (alamos01.colegioalamos.edu.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnZA+TDOLU7c; Wed, 30 Apr 2008 12:25:21 -0500 (CDT) Received: by alamos01.colegioalamos.edu.mx (Postfix, from userid 33) id B20CE23026D; Wed, 30 Apr 2008 12:25:19 -0500 (CDT) Received: from dial-pool63.lg.starcomms.net (dial-pool63.lg.starcomms.net [41.219.224.21]) by alamos.edu.mx (Horde MIME library) with HTTP; Wed, 30 Apr 2008 12:25:18 -0500 Message-ID: <20080430122518.16fd5yqog88844ok@alamos.edu.mx> Date: Wed, 30 Apr 2008 12:25:18 -0500 From: Ingeborg =?iso-8859-1?b?1nN0ZW5zb24=?= To: undisclosed-recipients:; Subject: CHARITY. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Mrs Ingeborg =D6stenson. Kammakargatan 30, P.O. Box 1158, SE-111 81 Stockholm, Sweden. Here writes Mrs Ingeborg =D6stenson, suffering from cancerous ailment. I am married to Gottfrid =D6stenson a Swedish who is dead. My husband was =20 into private practice all his life before his death. Our life together as man and wife lasted for three decades without child. My husband died after a protracted illness. My husband and I made a vow to uplift the down-trodden and the less= - privileged individuals as he had passion for persons who can not help themselves due to physical disability or financial predicament. I can adduce this to the fact that he needed a Child from this relationship, which never came. When my late husband was alive he deposited the sum of 5.2 Million =20 Pounds (Five Million two hundred thousand Pounds Sterling) which were derived from his va= st estates and investment in capital market with his bank here in Sweden. Presently, this money is still with the Bank. Recently, my Doctor told me th= at I have limited days to live due to the cancerous problems I am suffering fro= m. Though what bothers me most is the stroke that I have in addition to the cancer. With this hard reality that has befallen my family, and me I have decided to donate this fund to you and want you to use this gift which comes from my husbands effort to fund the upkeep of widows, widowers, orphans, destitute, the down-trodden, physically challenged children, barren-women an= d persons who prove to be genuinely handicapped financially. It is often said that blessed is the hand that gives. I took this decision because I do not have any child that will inherit this money and my husband relatives are bourgeois and very wealthy persons and I do not want my =20 husband?s hard earned money to be misused or invested into ill perceived ventures. I d= o not want a situation where this money will be used in an ungodly manner, hen= ce the reason for taking this bold decision. I am not afraid of death =20 hence I know where I am going. I know that I am going to be with the giver of life the Almighty when I eventually pass on. The Almighty will fight my case =20 and I shall hold my peace. I do not need any telephone communication in this regard due = to my deteriorating health and because of the presence of my husband?s relative= s around me. I do not want them to know about this development. As soon as I receive your reply I shall give you the contact of the bank in Sweden. I will also issue you a Letter of Authority that will empower you as the original beneficiary of this fund. My happiness is that I lived a life worthy of emulation. Please always be prayerful all through your life. Pleas= e assure me that you will act just as I have stated herein. Respond to me at: ingeborg.19@hotmail.com Hope to hear from you soon. Faithfully yours, Ingeborg =D6stenson.