From mailnull@www1.ietf.org Sat Feb 1 00:32:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29412 for ; Sat, 1 Feb 2003 00:32:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h115aE709931 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 00:36:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h115aAJ09926; Sat, 1 Feb 2003 00:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h115YLJ09891 for ; Sat, 1 Feb 2003 00:34:21 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29362 for ; Sat, 1 Feb 2003 00:29:59 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3A916137F08; Fri, 31 Jan 2003 21:33:32 -0800 (PST) Date: Fri, 31 Jan 2003 21:33:27 -0800 Subject: Re: [Enum] On the question of DNSSEC and recommended Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Jim Reid , Michael Mealling , Richard Shockey , enum@ietf.org To: "Conroy, Lawrence (SMTP)" From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lawrence, On Friday, January 31, 2003, at 04:35 PM, Conroy, Lawrence (SMTP) wrote: > So...If I understand the comments so far, the aim is to > require all resolvers (and I assume thus *all* ENUM Clients) No. DNSSEC (in this context) only applies to recursive resolvers (that is, caching servers). ENUM clients are typically stub resolvers which send queries to recursive servers and wait for responses. The ENUM clients should use TSIG and verify the AD bit is on in the response from the recursive server. Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Feb 1 09:31:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06478 for ; Sat, 1 Feb 2003 09:31:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11EZRx22200 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 09:35:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11EZOJ22192; Sat, 1 Feb 2003 09:35:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11EWhJ21842 for ; Sat, 1 Feb 2003 09:32:43 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06420 for ; Sat, 1 Feb 2003 09:28:11 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Feb 2003 14:31:44 -0000 Received: from percy.roke.co.uk ([193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CN3DAJ9T; Sat, 1 Feb 2003 14:31:42 -0000 From: "Conroy, Lawrence (SMTP)" To: David Conrad Cc: Jim Reid , Michael Mealling , Richard Shockey , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 1 Feb 2003 14:31:36 +0000 Subject: Re: [Enum] On the question of DNSSEC and recommended Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 9:33 pm -0800 31/1/03, David Conrad wrote: >Lawrence, > >On Friday, January 31, 2003, at 04:35 PM, Conroy, Lawrence (SMTP) wrote: >> So...If I understand the comments so far, the aim is to >>require all resolvers (and I assume thus *all* ENUM Clients) > >No. DNSSEC (in this context) only applies to recursive resolvers >(that is, caching servers). ENUM clients are typically stub >resolvers which send queries to recursive servers and wait for >responses. The ENUM clients should use TSIG and verify the AD bit >is on in the response from the recursive server. > >Rgds, >-drc > Hi David, folks, OK, so to re-phrase... ENUM Clients will use an external recursive resolver & use TSIG in their queries and in processing responses, or support DNSSEC with EDNS if they "go direct" (i.e. they do not go via an external Recursive Resolver). Simple resolvers are just not possible in this world. It seem to this outsider that there's pain for all, so that some who want to check security can. Unless I misunderstand completely, I feel that this will need a deal more justification for "non-DNS" folk than has been done so far - this needs to be sold! all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Feb 1 12:19:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11469 for ; Sat, 1 Feb 2003 12:19:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11HNgi05707 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 12:23:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11HNcJ05701; Sat, 1 Feb 2003 12:23:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11HKXJ05413 for ; Sat, 1 Feb 2003 12:20:33 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11408 for ; Sat, 1 Feb 2003 12:15:57 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 8B88F137F0A; Sat, 1 Feb 2003 09:19:31 -0800 (PST) To: David Conrad Cc: "Conroy, Lawrence (SMTP)" , Michael Mealling , Richard Shockey , enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: Message from David Conrad of "Fri, 31 Jan 2003 21:33:27 PST." Date: Sat, 01 Feb 2003 09:19:31 -0800 Message-ID: <68438.1044119971@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "David" == David Conrad writes: David> No. DNSSEC (in this context) only applies to recursive David> resolvers (that is, caching servers). ENUM clients are David> typically stub resolvers which send queries to recursive David> servers and wait for responses. David> The ENUM clients should use TSIG and verify the AD bit is David> on in the response from the recursive server. Perhaps the draft should say something about securing the path between the ENUM client and its resolving name server? I think there will be circumstances when TSIG with AD won't work because the client and resolver won't have established a trust relationship. For instance a roving user on a wireless LAN (at say IETF). The client could end up using the LAN's DNS server for resolution without knowing its TSIG key (if it has one). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Feb 1 12:37:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12117 for ; Sat, 1 Feb 2003 12:37:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11Hf8q10777 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 12:41:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11Hf7J10772; Sat, 1 Feb 2003 12:41:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11Hc0J10186 for ; Sat, 1 Feb 2003 12:38:00 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11952 for ; Sat, 1 Feb 2003 12:33:23 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 9A47E137F0A; Sat, 1 Feb 2003 09:36:57 -0800 (PST) To: "Conroy, Lawrence (SMTP)" Cc: David Conrad , Michael Mealling , Richard Shockey , enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: Message from "Conroy, Lawrence (SMTP)" of "Sat, 01 Feb 2003 14:31:36 GMT." Date: Sat, 01 Feb 2003 09:36:57 -0800 Message-ID: <68663.1044121017@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Lawrence" == Conroy, Lawrence (SMTP) writes: Lawrence> Hi David, folks, OK, so to re-phrase... ENUM Clients Lawrence> will use an external recursive resolver & use TSIG in Lawrence> their queries and in processing responses, or support Lawrence> DNSSEC with EDNS if they "go direct" (i.e. they do not Lawrence> go via an external Recursive Resolver). Simple resolvers Lawrence> are just not possible in this world. Simple resolvers -- for some definition of simple -- should be OK. They will probably have to do EDNS0 anyway. It's likely that there will be a bunch of NAPTR records for a given phone number and these will be too big to fit into the old-style 512 byte DNS payloads. What has to be ensured is that simple ENUM resolvers don't die or get indigestion if an answer contains DNSSEC signatures. BTW, IDN and IPv6 stuff is likely to mean even more bloated DNS answers too. Lawrence> It seem to this outsider that there's pain for all, so Lawrence> that some who want to check security can. Unless I Lawrence> misunderstand completely, I feel that this will need a Lawrence> deal more justification for "non-DNS" folk than has been Lawrence> done so far - this needs to be sold! It shouldn't need to be sold. Without DNSSEC and/or TSIG, answers from name servers can't be trusted. What more incentive is there than that for enduring the pain of DNSSEC? The alternative of not validating DNS answers and having to deal with spoofing attacks, cache poisoning, number hi-jacking, impersonation, and so on will be far more painful. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Feb 1 13:02:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12746 for ; Sat, 1 Feb 2003 13:02:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11I6Gx15138 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 13:06:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11I6FJ15133; Sat, 1 Feb 2003 13:06:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11I30J14753 for ; Sat, 1 Feb 2003 13:03:00 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12657 for ; Sat, 1 Feb 2003 12:58:22 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 6C110137F0A; Sat, 1 Feb 2003 10:01:56 -0800 (PST) Date: Sat, 1 Feb 2003 10:01:55 -0800 Subject: Re: [Enum] On the question of DNSSEC and recommended Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Jim Reid , Michael Mealling , Richard Shockey , enum@ietf.org To: "Conroy, Lawrence (SMTP)" From: David Conrad In-Reply-To: Message-Id: <400194B9-360F-11D7-933A-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lawrence, On Saturday, February 1, 2003, at 06:31 AM, Conroy, Lawrence (SMTP) wrote: > ENUM Clients will use an external recursive resolver & use TSIG > in their queries and in processing responses, As Jim notes, there are situations in where TSIG may not be appropriate. If you trust the network you are on (e.g., you are running a full caching server on your machine and are communicating to it via localhost) or you have established trust in some other way (e.g., IPSEC) you don't need TSIG. > or support DNSSEC > with EDNS if they "go direct" (i.e. they do not go via an external > Recursive Resolver). Simple resolvers are just not possible in this > world. As described above, a simple resolver is possible assuming the trust model is understood. > It seem to this outsider that there's pain for all, so that > some who want to check security can. Unless I misunderstand > completely, I feel that this will need a deal more justification > for "non-DNS" folk than has been done so far - this needs to be sold! Just to be clear, the point of all this DNSSEC goop is because the DNS as defined is an insecure protocol. The assumption is that people generally want to connect to the party whose number they've dialed instead of a party who has spoofed the DNS response to point a telephone number to (say) a $10/minute 1-900 number (or whatever). With regards to pain, there will be administrative overhead at the tier 1 level due to the need to sign the zones and deal with key rollover. From the perspective of the end user, there won't be that much pain as all that would be required is to establish a trust relationship with a caching server. From the perspective of ISPs, nothing changes (as long as they are running caching servers that validate DNSSEC responses). From the perspective of ENUM application writers, there is as much pain as you want to inflict upon yourselves (i.e., if you want to push establishment of trust onto somebody else, all you need to is verify the AD bit in the response. Alternatively, you can implement a full validating caching resolver if you _really_ like pain. The decision as to which way to go will probably end up being driven by customer demand). Rgds, -drc _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Feb 1 13:04:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12978 for ; Sat, 1 Feb 2003 13:04:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11I93M17930 for enum-archive@odin.ietf.org; Sat, 1 Feb 2003 13:09:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11I93J17921; Sat, 1 Feb 2003 13:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11Hw7J14293 for ; Sat, 1 Feb 2003 12:58:07 -0500 Received: from momotombo.TechFak.Uni-Bielefeld.DE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12589 for ; Sat, 1 Feb 2003 12:53:30 -0500 (EST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h11Hv4U28270; Sat, 1 Feb 2003 18:57:04 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h11Hv4L20410; Sat, 1 Feb 2003 18:57:04 +0100 (MET) Message-Id: <200302011757.h11Hv4L20410@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Jim Reid Cc: enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-reply-to: Your message of "Sat, 01 Feb 2003 09:36:57 PST." <68663.1044121017@shell.nominum.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Sat, 01 Feb 2003 18:57:03 +0100 From: Peter Koch Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > It shouldn't need to be sold. Without DNSSEC and/or TSIG, answers from > name servers can't be trusted. What more incentive is there than that Agreed, but wouldn't this suggest to extend the DNSSEC recommendation beyond the e164.arpa tree to also ensure authenticity and integrity of the targets of those NAPTR RRs? If not, where to draw the line? -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 5 00:04:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15831 for ; Wed, 5 Feb 2003 00:04:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h155AB817985 for enum-archive@odin.ietf.org; Wed, 5 Feb 2003 00:10:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h155A1J17980; Wed, 5 Feb 2003 00:10:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1557vJ17883 for ; Wed, 5 Feb 2003 00:07:57 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15767 for ; Wed, 5 Feb 2003 00:01:37 -0500 (EST) Received: from Ripplecl1248 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H9T00M0OKPWAO@mta0.huawei.com> for enum@ietf.org; Wed, 05 Feb 2003 13:03:35 +0800 (CST) Date: Wed, 05 Feb 2003 10:43:40 +0530 From: Ripple To: enum@ietf.org Reply-to: Ripple Message-id: <002f01c2ccd5$5b9fe0e0$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_Iq/f55H4Pm7IMV4DYESx6w)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Enum] DNS issue Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_Iq/f55H4Pm7IMV4DYESx6w) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, I have two simple DNS issues as follows, thanks for your help firstly: There are the description in Section 3.6.1 in RFC1034: "For example, we might show the RRs carried in a message as: ISI.EDU. MX 10 VENERA.ISI.EDU. MX 10 VAXA.ISI.EDU. VENERA.ISI.EDU. A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33 " 1. I am not sure the records only in Answer Section or in both Answer and Additional Section. I understand the latter the right. 2. if just the MX records in the Answer, do the two records use one Answer header or two? I think it is one but I am not sure. Is there this condition that the above two records have diferent TTL or Class, so they use different Answer header? Thanks, Ripple --Boundary_(ID_Iq/f55H4Pm7IMV4DYESx6w) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
      I have two simple DNS issues as follows, thanks for your help firstly:
 
    There are the description in Section 3.6.1 in RFC1034:
    "For example, we might show the RRs carried in a message as:
 
    ISI.EDU.                  MX              10 VENERA.ISI.EDU.
                                  MX               10 VAXA.ISI.EDU.
    VENERA.ISI.EDU.    A                128.9.0.32
                                   A                10.1.0.52
    VAXA.ISI.EDU.         A                10.2.0.27
                                   A                128.9.0.33                "
 
   1. I am not sure the records only in Answer Section or in both Answer and Additional Section. I understand the latter the right.
   2. if just the MX records in the Answer, do the two records use one Answer header or two? I think it is one but I am not sure. Is there this condition that the above two records have diferent TTL or Class, so they use different Answer header?
 
Thanks,
Ripple
--Boundary_(ID_Iq/f55H4Pm7IMV4DYESx6w)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 05:29:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11553 for ; Thu, 6 Feb 2003 05:29:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16AaHx19837 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 05:36:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AZwp19820; Thu, 6 Feb 2003 05:35:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AWrp19715 for ; Thu, 6 Feb 2003 05:32:53 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11468 for ; Thu, 6 Feb 2003 05:25:58 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] On the question of DNSSEC and recommended MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 2003 11:33:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DEF0C@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] On the question of DNSSEC and recommended Thread-Index: AcLKHpAQ+UjVKst1RqmMbaUCjlxjmgDqWNGw From: "Stastny Richard" To: "Peter Koch" , "Jim Reid" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16AWwp19716 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi folks, sorry for getting on this thread so late, but I was a bit busy the last week on real ENUM issues ;-) I now had time to read through it and finally came to the same conclusion as raised in the last message: where to draw the line? But first one comment to DNSSEC for ENUM and the requested change in rfc2916bis: I consider it to be too premature to put such a strong statement in rfc2916bis as requested by MM and Jim at this time, IMHO there is too many open issues yet with DNSSEC as this thread shows. I have no problem with trials using DNSSEC but I do not ENUM trials be sidetracked by solving principle DNS problems. It is hard enough to get plain DNS and ENUM over the table an sell it and there is a lot of other issues to solve first. Before DNSSEC is implemented in ENUM I would like to see it feasabely implemented somewhere else. And this leads to the second point. As I understand ENUM, it will be mainly used to retrieve a NAPTR with an URI pointing to something else, e.g. sip:user@foo.microsoft.net. I also understand that the next thing I have to do is to resolve foo.microsoft.net to find the sip-server of foo.microsoft.net (if MS is changing his mind again and put sip back in the messenger;-) So what is the reason to get in all this hassle with DNSSEC in e164.arpa, as long as .net is not secure? I am just wondering why the discussion stopped dead on this list after the very valid question from Peter? If you want to implement DNSSEC for ENUM, you have to start at the root servers and in all domains, not in e164.arpa only. There is no line to draw. regards Richard > -----Original Message----- > From: Peter Koch [mailto:pk@techfak.uni-bielefeld.de] > Sent: Saturday, February 01, 2003 6:57 PM > To: Jim Reid > Cc: enum@ietf.org > Subject: Re: [Enum] On the question of DNSSEC and recommended > > > > > It shouldn't need to be sold. Without DNSSEC and/or TSIG, > answers from > > name servers can't be trusted. What more incentive is there > than that > > Agreed, but wouldn't this suggest to extend the DNSSEC > recommendation beyond the e164.arpa tree to also ensure > authenticity and integrity of the targets of those NAPTR RRs? > If not, where to draw the line? > > -Peter > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 06:33:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13821 for ; Thu, 6 Feb 2003 06:33:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16BdtI25337 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 06:39:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Bdop25331; Thu, 6 Feb 2003 06:39:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Baop24530 for ; Thu, 6 Feb 2003 06:36:50 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13667 for ; Thu, 6 Feb 2003 06:29:53 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id BDFB5137F05; Thu, 6 Feb 2003 03:33:31 -0800 (PST) To: "Stastny Richard" Cc: "Peter Koch" , enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: Message from "Stastny Richard" of "Thu, 06 Feb 2003 11:33:10 +0100." <06CF906FE3998C4E944213062009F1620DEF0C@oefeg-s02.oefeg.loc> Date: Thu, 06 Feb 2003 03:33:31 -0800 Message-ID: <81126.1044531211@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> I consider it to be too premature to put such a strong Richard> statement in rfc2916bis as requested by MM and Jim at Richard> this time, IMHO there is too many open issues yet with Richard> DNSSEC as this thread shows. I have no problem with Richard> trials using DNSSEC but I do not ENUM trials be Richard> sidetracked by solving principle DNS problems. It is hard Richard> enough to get plain DNS and ENUM over the table an sell Richard> it and there is a lot of other issues to solve first. Nobody is suggesting that ENUM activities should solve DNS problems. Or that DNSSEC would "sidetrack" trials. [And even if it did, surely that's a matter for the people running those trials?] The text says DNSSEC is "recommended" so trials can choose to experiment with it or not. I think it would be foolish for a trial not do investigate DNSSEC since (a) we know the DNS is not secure; (b) we must be able to validate data in the 164.arpa tree or else E.164 falls apart; (c) DNSSEC is the only game in town for validating the DNS. There is no alternative. There's no choice between DNSSEC and something else. It's DNSSEC or nothing. What do you suggest? I appreciate that selling ENUM is hard in these difficult times. Even more so if DNSSEC is in there too. But the alternative of not doing that is worse if the DNS gets spoofed. Ignoring the potential damage that will undoubtedly cause is irresponsible. Richard> Before DNSSEC is implemented in ENUM I would like to see Richard> it feasabely implemented somewhere else. If everyone takes that attitude, we get nowhere because it's always somebody else's problem. ENUM will be an ideal place to experiment with DNSSEC, mainly because there is no significant installed base, no backwards compatibility issues and ENUM applications are still under development so there should be engineering momentum for making those things DNSSEC-aware. After all, we *know* that one day ENUM stuff will have to be DNSSEC aware. There are other DNSSEC activities. RIPE NCC's DISI project for their in-addr.arpa tree is the most visible. These are hampered by having an installed base and backwards compatibility considerations. Neither of these things are significant concerns in the virgin territory of e164.arpa. Richard> So what is the reason to get in all this hassle with Richard> DNSSEC in e164.arpa, as long as .net is not secure? Because if e164.arpa is secure -- and this can be done much more easily than other parts of the name space -- it means we can at least be sure that those lookups can be validated. We can start by being certain that the NAPTR records you looked up for my phone number are exactly what I put in the DNS. That alone has to be worthwhile, no? Maybe these NAPTRs point only at tel: URIs, so if my DNS data is signed, that has to be a Very Good Thing. You'll know for sure if that tel: URI really does point at a premium rate number or not. If the NAPTR records do point at SIP URIs, then I as the owner of some ENUM delegation have the choice of putting the SIP server under a secure part of the tree or not. For instance, I could duplicate the address of Microsoft's SIP server with an entry in my signed zone under 4.4.e164.arpa. So even if microsoft.com isn't signed, there could be a signed NAPTR record for sip.microsoft.com, albeit one depending on a duplicate A/AAAA record for that SIP server that lives at say sip.microsoft.1.2.3.4.4.e164.arpa. It's ugly but could help until such times as microsoft.com was signed and there was a chain of trust all the way to the root. Richard> I am just wondering why the discussion stopped dead on Richard> this list after the very valid question from Peter? Well in my case it's because I've been too busy with "real ENUM work" :-) and not had time to respond yet. I think I've partially just done that above. Richard> If you want to implement DNSSEC for ENUM, you have to Richard> start at the root servers and in all domains, not in Richard> e164.arpa only. There is no line to draw. In principle, yes. In practice no. Signing the root is fraught with all sorts of political problems. Some of them were raised in Johan Ihren's presentation in the DNS WG at RIPE last week. Signing infrastructure stuff under .arpa is a good place to start. It doesn't involve ICANN or the DoC. e164.arpa is an attractve choice for the reasons I gave earlier. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 07:10:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15042 for ; Thu, 6 Feb 2003 07:10:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16CH9Y27659 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 07:17:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CH8p27654; Thu, 6 Feb 2003 07:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CEap27563 for ; Thu, 6 Feb 2003 07:14:36 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14966 for ; Thu, 6 Feb 2003 07:07:38 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] On the question of DNSSEC and recommended MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 2003 13:14:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DEF0E@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] On the question of DNSSEC and recommended Thread-Index: AcLN1BWpbS3JPlLBTjG1Kvy5B0YT3AAAtAcQ From: "Stastny Richard" To: "Jim Reid" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16CEap27564 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jim, nice to hear that you are also busy with ENUM work ;-) and I will try to catch up with the RIPE issues dicussed last week. The major problem I have with your proposal is to see the MUSTs NOW in RFC2916bis: "At the point at which DNSSEC becomes a Draft Standard, it MUST be implemented by ENUM compliant systems." Some may get the idea to prevent DNSSEC to get a Draft Standard ;-) I also have problems with this: "Additionally, due to the fact that some parts of the ENUM system may be using DNSSEC before others, resolvers MUST be capable of handling responses containing DNSSEC-related RR types even in cases where the resolver or client application is unwilling or unable to perform DNSSEC validation." See the comments from Lawrence. I have a problem here because I do not yet fully understand the implications of this. I have learned during the discussions on the enumservices that the clients out there may be so dumb that they cannot evaluate the regexp of all NAPTRs first, so they have to select the NAPTR only with the enumservice, but the same dumb clients (example was always mobile phones) now MUST be fully capable of handling DNSSEC. I am just wondering. regards Richard > -----Original Message----- > From: Jim Reid [mailto:Jim.Reid@nominum.com] > Sent: Thursday, February 06, 2003 12:34 PM > To: Stastny Richard > Cc: Peter Koch; enum@ietf.org > Subject: Re: [Enum] On the question of DNSSEC and recommended > > > >>>>> "Richard" == Stastny Richard writes: > > Richard> I consider it to be too premature to put such a strong > Richard> statement in rfc2916bis as requested by MM and Jim at > Richard> this time, IMHO there is too many open issues yet with > Richard> DNSSEC as this thread shows. I have no problem with > Richard> trials using DNSSEC but I do not ENUM trials be > Richard> sidetracked by solving principle DNS problems. It is hard > Richard> enough to get plain DNS and ENUM over the table an sell > Richard> it and there is a lot of other issues to solve first. > > Nobody is suggesting that ENUM activities should solve DNS > problems. Or that DNSSEC would "sidetrack" trials. [And even > if it did, surely that's a matter for the people running > those trials?] The text says DNSSEC is "recommended" so > trials can choose to experiment with it or not. I think it > would be foolish for a trial not do investigate DNSSEC since > (a) we know the DNS is not secure; (b) we must be able to > validate data in the 164.arpa tree or else E.164 falls apart; > (c) DNSSEC is the only game in town for validating the DNS. > There is no alternative. There's no choice between DNSSEC and > something else. It's DNSSEC or nothing. What do you suggest? > > I appreciate that selling ENUM is hard in these difficult > times. Even more so if DNSSEC is in there too. But the > alternative of not doing that is worse if the DNS gets > spoofed. Ignoring the potential damage that will undoubtedly > cause is irresponsible. > > Richard> Before DNSSEC is implemented in ENUM I would like to see > Richard> it feasabely implemented somewhere else. > > If everyone takes that attitude, we get nowhere because it's > always somebody else's problem. ENUM will be an ideal place > to experiment with DNSSEC, mainly because there is no > significant installed base, no backwards compatibility issues > and ENUM applications are still under development so there > should be engineering momentum for making those things > DNSSEC-aware. After all, we *know* that one day ENUM stuff > will have to be DNSSEC aware. > > There are other DNSSEC activities. RIPE NCC's DISI project > for their in-addr.arpa tree is the most visible. These are > hampered by having an installed base and backwards > compatibility considerations. Neither of these things are > significant concerns in the virgin territory of e164.arpa. > > Richard> So what is the reason to get in all this hassle with > Richard> DNSSEC in e164.arpa, as long as .net is not secure? > > Because if e164.arpa is secure -- and this can be done much > more easily than other parts of the name space -- it means we > can at least be sure that those lookups can be validated. We > can start by being certain that the NAPTR records you looked > up for my phone number are exactly what I put in the DNS. > That alone has to be worthwhile, no? Maybe these NAPTRs point > only at tel: URIs, so if my DNS data is signed, that has to > be a Very Good Thing. You'll know for sure if that > tel: URI really does point at a premium rate number or not. > If the NAPTR records do point at SIP URIs, then I as the > owner of some ENUM delegation have the choice of putting the > SIP server under a secure part of the tree or not. For > instance, I could duplicate the address of Microsoft's SIP > server with an entry in my signed zone under 4.4.e164.arpa. > So even if microsoft.com isn't signed, there could be a > signed NAPTR record for sip.microsoft.com, albeit one > depending on a duplicate A/AAAA record for that SIP server > that lives at say sip.microsoft.1.2.3.4.4.e164.arpa. It's > ugly but could help until such times as microsoft.com was > signed and there was a chain of trust all the way to the root. > > Richard> I am just wondering why the discussion stopped dead on > Richard> this list after the very valid question from Peter? > > Well in my case it's because I've been too busy with "real ENUM work" > :-) and not had time to respond yet. I think I've partially > just done that above. > > Richard> If you want to implement DNSSEC for ENUM, you have to > Richard> start at the root servers and in all domains, not in > Richard> e164.arpa only. There is no line to draw. > > In principle, yes. In practice no. Signing the root is > fraught with all sorts of political problems. Some of them > were raised in Johan Ihren's presentation in the DNS WG at > RIPE last week. Signing infrastructure stuff under .arpa is a > good place to start. It doesn't involve ICANN or the DoC. > e164.arpa is an attractve choice for the reasons I gave earlier. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 07:22:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15311 for ; Thu, 6 Feb 2003 07:22:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16CT9U28139 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 07:29:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CT8p28134; Thu, 6 Feb 2003 07:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CQrp28028 for ; Thu, 6 Feb 2003 07:26:53 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15245 for ; Thu, 6 Feb 2003 07:19:54 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h16CNS201500; Thu, 6 Feb 2003 04:23:28 -0800 (PST) From: Bill Manning Message-Id: <200302061223.h16CNS201500@boreas.isi.edu> Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: <06CF906FE3998C4E944213062009F1620DEF0E@oefeg-s02.oefeg.loc> from Stastny Richard at "Feb 6, 3 01:14:51 pm" To: Richard.Stastny@oefeg.at (Stastny Richard) Date: Thu, 6 Feb 2003 04:23:28 -0800 (PST) Cc: Jim.Reid@nominum.com, enum@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit % I also have problems with this: % % "Additionally, due to the fact that some parts of the ENUM system may % % be using DNSSEC before others, resolvers MUST be capable of handling % responses containing DNSSEC-related RR types even in cases where the % resolver or client application is unwilling or unable to perform % DNSSEC validation." % % See the comments from Lawrence. I have a problem here because I do not % yet fully understand the implications of this. I have learned % during the discussions on the enumservices that the clients % out there may be so dumb that they cannot evaluate the regexp of all % NAPTRs first, % so they have to select the NAPTR only with the enumservice, but the same % dumb clients (example was always mobile phones) now MUST be fully % capable % of handling DNSSEC. From here, I think this means that there is no flag day. Some parts of the DNS infrastrucuture will be signed before other parts and if ENUM systems expect anything different, e.g. everything is or is not signed, then such a system will find -very- limited deployment. % % I am just wondering. % % regards % Richard % % > -----Original Message----- % > From: Jim Reid [mailto:Jim.Reid@nominum.com] % > Sent: Thursday, February 06, 2003 12:34 PM % > To: Stastny Richard % > Cc: Peter Koch; enum@ietf.org % > Subject: Re: [Enum] On the question of DNSSEC and recommended % > % > % > >>>>> "Richard" == Stastny Richard writes: % > % > Richard> I consider it to be too premature to put such a strong % > Richard> statement in rfc2916bis as requested by MM and Jim at % > Richard> this time, IMHO there is too many open issues yet with % > Richard> DNSSEC as this thread shows. I have no problem with % > Richard> trials using DNSSEC but I do not ENUM trials be % > Richard> sidetracked by solving principle DNS problems. It is hard % > Richard> enough to get plain DNS and ENUM over the table an sell % > Richard> it and there is a lot of other issues to solve first. % > % > Nobody is suggesting that ENUM activities should solve DNS % > problems. Or that DNSSEC would "sidetrack" trials. [And even % > if it did, surely that's a matter for the people running % > those trials?] The text says DNSSEC is "recommended" so % > trials can choose to experiment with it or not. I think it % > would be foolish for a trial not do investigate DNSSEC since % > (a) we know the DNS is not secure; (b) we must be able to % > validate data in the 164.arpa tree or else E.164 falls apart; % > (c) DNSSEC is the only game in town for validating the DNS. % > There is no alternative. There's no choice between DNSSEC and % > something else. It's DNSSEC or nothing. What do you suggest? % > % > I appreciate that selling ENUM is hard in these difficult % > times. Even more so if DNSSEC is in there too. But the % > alternative of not doing that is worse if the DNS gets % > spoofed. Ignoring the potential damage that will undoubtedly % > cause is irresponsible. % > % > Richard> Before DNSSEC is implemented in ENUM I would like to see % > Richard> it feasabely implemented somewhere else. % > % > If everyone takes that attitude, we get nowhere because it's % > always somebody else's problem. ENUM will be an ideal place % > to experiment with DNSSEC, mainly because there is no % > significant installed base, no backwards compatibility issues % > and ENUM applications are still under development so there % > should be engineering momentum for making those things % > DNSSEC-aware. After all, we *know* that one day ENUM stuff % > will have to be DNSSEC aware. % > % > There are other DNSSEC activities. RIPE NCC's DISI project % > for their in-addr.arpa tree is the most visible. These are % > hampered by having an installed base and backwards % > compatibility considerations. Neither of these things are % > significant concerns in the virgin territory of e164.arpa. % > % > Richard> So what is the reason to get in all this hassle with % > Richard> DNSSEC in e164.arpa, as long as .net is not secure? % > % > Because if e164.arpa is secure -- and this can be done much % > more easily than other parts of the name space -- it means we % > can at least be sure that those lookups can be validated. We % > can start by being certain that the NAPTR records you looked % > up for my phone number are exactly what I put in the DNS. % > That alone has to be worthwhile, no? Maybe these NAPTRs point % > only at tel: URIs, so if my DNS data is signed, that has to % > be a Very Good Thing. You'll know for sure if that % > tel: URI really does point at a premium rate number or not. % > If the NAPTR records do point at SIP URIs, then I as the % > owner of some ENUM delegation have the choice of putting the % > SIP server under a secure part of the tree or not. For % > instance, I could duplicate the address of Microsoft's SIP % > server with an entry in my signed zone under 4.4.e164.arpa. % > So even if microsoft.com isn't signed, there could be a % > signed NAPTR record for sip.microsoft.com, albeit one % > depending on a duplicate A/AAAA record for that SIP server % > that lives at say sip.microsoft.1.2.3.4.4.e164.arpa. It's % > ugly but could help until such times as microsoft.com was % > signed and there was a chain of trust all the way to the root. % > % > Richard> I am just wondering why the discussion stopped dead on % > Richard> this list after the very valid question from Peter? % > % > Well in my case it's because I've been too busy with "real ENUM work" % > :-) and not had time to respond yet. I think I've partially % > just done that above. % > % > Richard> If you want to implement DNSSEC for ENUM, you have to % > Richard> start at the root servers and in all domains, not in % > Richard> e164.arpa only. There is no line to draw. % > % > In principle, yes. In practice no. Signing the root is % > fraught with all sorts of political problems. Some of them % > were raised in Johan Ihren's presentation in the DNS WG at % > RIPE last week. Signing infrastructure stuff under .arpa is a % > good place to start. It doesn't involve ICANN or the DoC. % > e164.arpa is an attractve choice for the reasons I gave earlier. % > % _______________________________________________ % enum mailing list % enum@ietf.org % https://www1.ietf.org/mailman/listinfo/enum % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 08:32:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17358 for ; Thu, 6 Feb 2003 08:32:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Dd0K00360 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 08:39:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Dcup00355; Thu, 6 Feb 2003 08:38:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Dbvp00330 for ; Thu, 6 Feb 2003 08:37:57 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17328 for ; Thu, 6 Feb 2003 08:30:57 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 2003 14:38:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DEF10@oefeg-s02.oefeg.loc> Thread-Topic: A/AAAA records Thread-Index: AcLN1BWpbS3JPlLBTjG1Kvy5B0YT3AADyXtQ From: "Stastny Richard" To: "Jim Reid" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16Dbvp00331 Subject: [Enum] A/AAAA records Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jim, You wrote: > For > instance, I could duplicate the address of Microsoft's SIP > server with an entry in my signed zone under 4.4.e164.arpa. > So even if microsoft.com isn't signed, there could be a > signed NAPTR record for sip.microsoft.com, albeit one > depending on a duplicate A/AAAA record for that SIP server > that lives at say sip.microsoft.1.2.3.4.4.e164.arpa. It's > ugly but could help until such times as microsoft.com was > signed and there was a chain of trust all the way to the root. > Huh? I have heard rumors about A records ENUM, but "say sip.microsoft.1.2.3.4.4.e164.arpa." is new for me. Do you now something I do not now and could you please elaborate. I do not know about the numbering plan in UK (who knows;-), but from my SG2 knowledge "+44321microsoftsip" does not look quite like an E.164 number, not even in Redmond. regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 11:13:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24055 for ; Thu, 6 Feb 2003 11:13:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16GJch11733 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 11:19:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GJYp11724; Thu, 6 Feb 2003 11:19:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GIUp11648 for ; Thu, 6 Feb 2003 11:18:30 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23997 for ; Thu, 6 Feb 2003 11:11:28 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id D80F8137F05; Thu, 6 Feb 2003 08:15:06 -0800 (PST) To: "Stastny Richard" Cc: enum@ietf.org Subject: Re: [Enum] A/AAAA records In-Reply-To: Message from "Stastny Richard" of "Thu, 06 Feb 2003 14:38:11 +0100." <06CF906FE3998C4E944213062009F1620DEF10@oefeg-s02.oefeg.loc> Date: Thu, 06 Feb 2003 08:15:06 -0800 Message-ID: <83974.1044548106@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: >> For instance, I could duplicate the address of Microsoft's SIP >> server with an entry in my signed zone under 4.4.e164.arpa. So >> even if microsoft.com isn't signed, there could be a signed >> NAPTR record for sip.microsoft.com, albeit one depending on a >> duplicate A/AAAA record for that SIP server that lives at say >> sip.microsoft.1.2.3.4.4.e164.arpa. It's ugly but could help >> until such times as microsoft.com was signed and there was a >> chain of trust all the way to the root. Richard> Huh? Richard> Do you now something I do not now and could you please Richard> elaborate. Sure. Suppose I own the 1.2.3.4.4.e164.arpa zone. It represents my telephone number. Assume Microsoft have a SIP server at address 10.9.8.7, called sip.microsoft.com. My zone is signed because e164.arpa is signed. microsoft.com isn't. My zone file could have a NAPTR record resembling: 1.2.3.4.4.e164.arpa. IN NAPTR .... "sip:jim@sip.microsoft.com" So there's a link from my signed zone to something which isn't signed; the scenario Peter raised recently. However if I add some stuff to the 1.2.3.4.4.e164.arpa zone, the info about that SIP server can be signed, although under a different name. The zone file might look like this (minus the SIGs and so on): 1.2.3.4.4.e164.arpa. IN NAPTR ... "jim@sip.microsoft.1.2.3.4.4.e164.arpa" sip.microsoft.1.2.3.4.4.e164.arpa. IN A 10.9.8.7 So provided I keep sip.microsoft.1.2.3.4.4.e164.arpa pointing at the IP address of Microsoft's SIP server, it will all just work fine. And it can all be signed with DNSSEC too since the A record above would be in my signed zone. And since this duplicate A record is in my zone, my name servers can return it and its signature along with the request for the NAPTR record, saving resolution of another domain name. This is just another application of the old computing maxim: any problem can be solved by adding another layer of indirection. I hope this clears up any confusion. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 11:32:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24905 for ; Thu, 6 Feb 2003 11:32:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16GdCO13519 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 11:39:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GdBp13514; Thu, 6 Feb 2003 11:39:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Gcip13494 for ; Thu, 6 Feb 2003 11:38:44 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24866 for ; Thu, 6 Feb 2003 11:31:41 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 66220137F06; Thu, 6 Feb 2003 08:35:16 -0800 (PST) To: "Stastny Richard" Cc: enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: Message from "Stastny Richard" of "Thu, 06 Feb 2003 13:14:51 +0100." <06CF906FE3998C4E944213062009F1620DEF0E@oefeg-s02.oefeg.loc> Date: Thu, 06 Feb 2003 08:35:16 -0800 Message-ID: <84293.1044549316@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> The major problem I have with your proposal is to see the Richard> MUSTs NOW in RFC2916bis: Richard> "At the point at which DNSSEC becomes a Draft Richard> Standard, it MUST be implemented by ENUM compliant Richard> systems." Richard> Some may get the idea to prevent DNSSEC to get a Draft Richard> Standard ;-) I think dnsext has enough people with that opinion already. :-) Richard> I also have problems with this: Richard> "Additionally, due to the fact that some parts of the Richard> ENUM system may Richard> be using DNSSEC before others, resolvers MUST be Richard> capable of handling responses containing DNSSEC-related Richard> RR types even in cases where the resolver or client Richard> application is unwilling or unable to perform DNSSEC Richard> validation." Richard> See the comments from Lawrence. I have a problem here Richard> because I do not yet fully understand the implications of Richard> this. The implication is resolvers have to be capable of handling DNS responses that contain SIG, NXT, KEY records and whatever. This should be no surprise to anyone. That does not necessarily mean to say resolvers must validate those signatures. At least not until DNSSEC is finished. Until then, at the very least, a resolver should not crash or misbehave because it sees a bigger than expected DNS response or "unknown" RR types. If the resolver is slightly smarter than that, it might want to tell the calling application it saw signed data which has not been validated. Or it might choose to pass the DNSSEC stuff via some API in case the calling application has some other means of doing the validation (eg lwres in BIND9). Richard> I have learned during the discussions on the Richard> enumservices that the clients out there may be so dumb Richard> that they cannot evaluate the regexp of all NAPTRs first, Richard> so they have to select the NAPTR only with the Richard> enumservice, but the same dumb clients (example was Richard> always mobile phones) now MUST be fully capable of Richard> handling DNSSEC. No. Though I suspect that's where we'll eventually be heading. I don't believe a resolver that has a trust relationship with a DNSSEC-aware name server will always be a valid assumption. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 11:41:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25231 for ; Thu, 6 Feb 2003 11:41:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16GmAX13885 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 11:48:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16GmAp13880; Thu, 6 Feb 2003 11:48:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Glmp13854 for ; Thu, 6 Feb 2003 11:47:48 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25205 for ; Thu, 6 Feb 2003 11:40:45 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] A/AAAA records MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Feb 2003 17:47:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DEF18@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] A/AAAA records Thread-Index: AcLN+2uUnw+748WQSXyV2AU/VOc4wgAAr1dQ From: "Stastny Richard" To: "Jim Reid" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16Glmp13855 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim Thanks for the clarification. I think I got the idea (maybe we have to chat about this in detail) Anyway, I do not assume anybody using ENUM (e.g. my mother) is a Nominum DNS specialist setting up his Tier 2 in this way;-) regards Richard PS: if I call +44321 on my mobile phone, you answer the call ;-) > -----Original Message----- > From: Jim Reid [mailto:Jim.Reid@nominum.com] > Sent: Thursday, February 06, 2003 5:15 PM > To: Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] A/AAAA records > > > >>>>> "Richard" == Stastny Richard writes: > > >> For instance, I could duplicate the address of Microsoft's SIP > >> server with an entry in my signed zone under 4.4.e164.arpa. So > >> even if microsoft.com isn't signed, there could be a signed > >> NAPTR record for sip.microsoft.com, albeit one depending on a > >> duplicate A/AAAA record for that SIP server that lives at say > >> sip.microsoft.1.2.3.4.4.e164.arpa. It's ugly but could help > >> until such times as microsoft.com was signed and there was a > >> chain of trust all the way to the root. > > Richard> Huh? > > Richard> Do you now something I do not now and could you please > Richard> elaborate. > > Sure. Suppose I own the 1.2.3.4.4.e164.arpa zone. It > represents my telephone number. Assume Microsoft have a SIP > server at address 10.9.8.7, called sip.microsoft.com. My zone > is signed because e164.arpa is signed. microsoft.com isn't. > My zone file could have a NAPTR record > resembling: > 1.2.3.4.4.e164.arpa. IN NAPTR .... > "sip:jim@sip.microsoft.com" So there's a link from my signed > zone to something which isn't signed; the scenario Peter > raised recently. However if I add some stuff to the > 1.2.3.4.4.e164.arpa zone, the info about that SIP server can > be signed, although under a different name. The zone file > might look like this (minus the SIGs and so on): > > 1.2.3.4.4.e164.arpa. IN NAPTR ... > "jim@sip.microsoft.1.2.3.4.4.e164.arpa" > sip.microsoft.1.2.3.4.4.e164.arpa. IN A 10.9.8.7 > > So provided I keep sip.microsoft.1.2.3.4.4.e164.arpa pointing > at the IP address of Microsoft's SIP server, it will all just > work fine. And it can all be signed with DNSSEC too since the > A record above would be in my signed zone. And since this > duplicate A record is in my zone, my name servers can return > it and its signature along with the request for the NAPTR > record, saving resolution of another domain name. This is > just another application of the old computing maxim: any > problem can be solved by adding another layer of indirection. > > I hope this clears up any confusion. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 12:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25926 for ; Thu, 6 Feb 2003 12:02:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16H9Dg16082 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 12:09:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16H9Cp16077; Thu, 6 Feb 2003 12:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16H85p16023 for ; Thu, 6 Feb 2003 12:08:05 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25848 for ; Thu, 6 Feb 2003 12:00:58 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id C7BB6137F05; Thu, 6 Feb 2003 09:04:35 -0800 (PST) To: "Stastny Richard" Cc: enum@ietf.org Subject: Re: [Enum] A/AAAA records In-Reply-To: Message from "Stastny Richard" of "Thu, 06 Feb 2003 17:47:58 +0100." <06CF906FE3998C4E944213062009F1620DEF18@oefeg-s02.oefeg.loc> Date: Thu, 06 Feb 2003 09:04:35 -0800 Message-ID: <84872.1044551075@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> PS: if I call +44321 on my mobile phone, you answer the Richard> call ;-) Sure, no problem. Just as long as your phone does ENUM lookups. I control the 4.4.e164.arpa zone file. :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 12:04:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26019 for ; Thu, 6 Feb 2003 12:04:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HB7h16214 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 12:11:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HB7p16209; Thu, 6 Feb 2003 12:11:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HAnp16194 for ; Thu, 6 Feb 2003 12:10:49 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26002 for ; Thu, 6 Feb 2003 12:03:47 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 05 Feb 2003 22:47:44 -0500 Subject: RE: [Enum] On the question of DNSSEC and recommended From: Michael Mealling To: Stastny Richard Cc: Peter Koch , Jim Reid , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DEF0C@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DEF0C@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1044551041.2304.140.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 06 Feb 2003 12:04:01 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-06 at 05:33, Stastny Richard wrote: > But first one comment to DNSSEC for ENUM and the requested change in > rfc2916bis: > > I consider it to be too premature to put such a strong statement in > rfc2916bis as requested by MM and Jim at this time, IMHO there is too many open > issues yet with DNSSEC as this thread shows. I have no problem with trials > using DNSSEC but I do not ENUM trials be sidetracked by solving principle DNS > problems. It is hard enough to get plain DNS and ENUM over the table an > sell it and there is a lot of other issues to solve first. > > Before DNSSEC is implemented in ENUM I would like to see it feasabely > implemented somewhere else. That is why the MUST is only there once DNSSEC goes to Draft Standard. To get to that point DNSSEC has to fairly bullet-proofed and implemented. Before Draft Standard you are free to ignore DNSSEC to your hearts content. The document says SHOULD instead of MUST. What it is saying is that you can ignore this requirement but you really should be aware of the security implications of what you are doing. > And this leads to the second point. As I understand ENUM, it will be > mainly used to retrieve a NAPTR with an URI pointing to something else, > e.g. sip:user@foo.microsoft.net. I also understand that the next thing I > have to do is to resolve foo.microsoft.net to find the sip-server of > foo.microsoft.net > (if MS is changing his mind again and put sip back in the messenger;-) > > So what is the reason to get in all this hassle with DNSSEC in > e164.arpa, as long as .net is not secure? Because if .net _is_ secured it won't matter one bit since the step prior to it isn't secured. While securing '.net' is harder, it is containable and deployable. But without ENUM being secured it simply won't matter. > I am just wondering why the discussion stopped dead on this list after > the very valid question from Peter? > > If you want to implement DNSSEC for ENUM, you have to start at the root > servers and in all domains, not in e164.arpa only. There is no line to draw. Yes there is. That capability is built into DNSSEC itself since everyone involved new that the ability to sign at that level was problematic. Your assertion is that the entire DNS tree has to be signed before its worthwhile to sign any portion of the tree and that's simply not true and absurd. DNSSEC wasn't built that way... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 12:11:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26346 for ; Thu, 6 Feb 2003 12:11:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HI7916556 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 12:18:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HI6p16551; Thu, 6 Feb 2003 12:18:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HHZp16487 for ; Thu, 6 Feb 2003 12:17:35 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26295 for ; Thu, 6 Feb 2003 12:10:32 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 05 Feb 2003 22:54:21 -0500 Subject: RE: [Enum] On the question of DNSSEC and recommended From: Michael Mealling To: Stastny Richard Cc: Jim Reid , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DEF0E@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DEF0E@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1044551438.4605.147.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 06 Feb 2003 12:10:38 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-06 at 07:14, Stastny Richard wrote: > The major problem I have with your proposal is to see the MUSTs NOW in > RFC2916bis: > > "At the > point at which DNSSEC becomes a Draft Standard, it MUST be > implemented by ENUM compliant systems." > > Some may get the idea to prevent DNSSEC to get a Draft Standard ;-) The point of the MUST being at Draft instead of Proposed is that once that level of standardization is obtained with DNSSEC it probably should be made a MUST for all new protocols anyway. The MUST isn't there for Proposed. There is an ___extremely___ important difference. If/When DNSSEC gets to Proposed I'm pretty sure the IETF will feel very strongly that you will have to have an extremely good reason to not require DNSSEC. > I also have problems with this: > > "Additionally, due to the fact that some parts of the ENUM system may > > be using DNSSEC before others, resolvers MUST be capable of handling > responses containing DNSSEC-related RR types even in cases where the > resolver or client application is unwilling or unable to perform > DNSSEC validation." > > See the comments from Lawrence. I have a problem here because I do not > yet fully understand the implications of this. I have learned > during the discussions on the enumservices that the clients > out there may be so dumb that they cannot evaluate the regexp of all > NAPTRs first, > so they have to select the NAPTR only with the enumservice, but the same > dumb clients (example was always mobile phones) now MUST be fully > capable > of handling DNSSEC. > > I am just wondering. The point here is that there have been resolvers that choked on unkown RR types. This is a violation of the DNS standard itself and simply a bad implementation. Being able to not fail when presented with an unknown RR type will not add any size or complexity to a 'dumb' device. Heck, there are RFID tags that have tiny built in cameras for taking pictures and transmitting them. I can't imagine what kind of requirements a device might have that it can't handle the minimum of not barfing when presented with DNSSEC RRs... Again, this requirement doesn't say you have to implement DNSSEC, you just have to not die if you see them in your responses... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 12:17:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26577 for ; Thu, 6 Feb 2003 12:17:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HORi16899 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 12:24:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HOQp16894; Thu, 6 Feb 2003 12:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HNBp16838 for ; Thu, 6 Feb 2003 12:23:11 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26518 for ; Thu, 6 Feb 2003 12:16:09 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 05 Feb 2003 23:00:07 -0500 Subject: RE: [Enum] A/AAAA records From: Michael Mealling To: Stastny Richard Cc: Jim Reid , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DEF18@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DEF18@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1044551784.2304.152.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 06 Feb 2003 12:16:25 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-06 at 11:47, Stastny Richard wrote: > Jim > Thanks for the clarification. > > I think I got the idea (maybe we have to chat about this in detail) > > Anyway, I do not assume anybody using ENUM (e.g. my mother) is a Nominum > DNS specialist setting up his Tier 2 in this way;-) Umm.. I don't think anyone is suggesting that your mother is going to be administering her own nameserver. Her service provider will probably be doing it for her at her direction. And I'm probably sure anyone who would be doing that function for a service provider will at least have a copy of DNS & BIND on their desk.... I appreciate your attempt to keep ENUM simplistic but I'm curious what your application requirements are that force you to want to make your implementation so simplistic as to be insecure and non-interoperable? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 12:18:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26608 for ; Thu, 6 Feb 2003 12:18:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HP3q16964 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 12:25:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HP3p16958; Thu, 6 Feb 2003 12:25:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HOop16920 for ; Thu, 6 Feb 2003 12:24:50 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26575 for ; Thu, 6 Feb 2003 12:17:46 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA30264 for ; Thu, 6 Feb 2003 09:21:08 -0800 Message-Id: <5.2.0.9.2.20030206121946.026c2420@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Feb 2003 12:20:25 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dnssec-intro-04.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Just a educational note to the list on what is being discussed here.... >To: IETF-Announce: ; >Cc: namedroppers@ops.ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-04.txt >Date: Thu, 06 Feb 2003 09:27:54 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : DNS Security Introduction and Requirements > Author(s) : R. Arends, M. Larson, D. Massey, S. Rose > Filename : draft-ietf-dnsext-dnssec-intro-04.txt > Pages : 20 > Date : 2003-2-5 > >The Domain Name System Security Extensions (DNSSEC) provide data >origin authentication and data integrity. This document introduces >these extensions and describes their capabilities and limitations. >The services that the security extensions provide and do not provide >are discussed. Lastly, the group of documents that describe the DNS >security extensions and their interrelationships is discussed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-dnsext-dnssec-intro-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-5135926.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 15:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04137 for ; Thu, 6 Feb 2003 15:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16L5r131012 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 16:05:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16L5jp31005; Thu, 6 Feb 2003 16:05:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16L4gp30958 for ; Thu, 6 Feb 2003 16:04:42 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04079 for ; Thu, 6 Feb 2003 15:57:35 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] A/AAAA records MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 6 Feb 2003 22:04:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DEF1E@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] A/AAAA records Thread-Index: AcLOAlVLQsbM5UMTTHmGNrMKea15OwAHzMZS From: "Stastny Richard" To: "Jim Reid" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h16L4gp30959 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim Reid wrote >>>>> "Richard" == Stastny Richard writes: Richard> PS: if I call +44321 on my mobile phone, you answer the Richard> call ;-) Sure, no problem. Just as long as your phone does ENUM lookups. I control the 4.4.e164.arpa zone file. :-) Be careful, I may have an enum-enabled mobile phone quicker than you have hacked your zone file ;-) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 6 19:12:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09983 for ; Thu, 6 Feb 2003 19:12:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h170JDe10858 for enum-archive@odin.ietf.org; Thu, 6 Feb 2003 19:19:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h170J7p10853; Thu, 6 Feb 2003 19:19:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h170Hsp10808 for ; Thu, 6 Feb 2003 19:17:54 -0500 Received: from tisch.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09917 for ; Thu, 6 Feb 2003 19:10:42 -0500 (EST) Received: from dialup-209.245.234.36.dial1.dallas1.level3.net ([209.245.234.36] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18gw9h-0003gA-00; Thu, 06 Feb 2003 19:14:09 -0500 Message-ID: <3E4316B3.AA00C497@ix.netcom.com> Date: Thu, 06 Feb 2003 18:15:16 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jim Reid CC: Stastny Richard , Peter Koch , enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended References: <81126.1044531211@shell.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim and all, I by in large agree with Jim's remarks and comments below. Right now there is no viable choice or alternative to DNSSEC for ENUM and to ignore that is irresponsible at a minimum. Indeed it may be that the IETF is not up to the task of finishing the DNSSEC open issues at this time of in a timely manner. We realized this some time ago and initiated our own commercial privately funded effort to address them along with improving what has been thus far undertaken by the IETF... ALthough the IETF may take our efforts are a slight to the IETF's capabilities, that is certainly not the intent. Unfortunately some here have seemingly expressed in so many words that attitude. This is unfortunate and should hopefully be beneath the IETF's ethical standards. Jim Reid wrote: > >>>>> "Richard" == Stastny Richard writes: > > Richard> I consider it to be too premature to put such a strong > Richard> statement in rfc2916bis as requested by MM and Jim at > Richard> this time, IMHO there is too many open issues yet with > Richard> DNSSEC as this thread shows. I have no problem with > Richard> trials using DNSSEC but I do not ENUM trials be > Richard> sidetracked by solving principle DNS problems. It is hard > Richard> enough to get plain DNS and ENUM over the table an sell > Richard> it and there is a lot of other issues to solve first. > > Nobody is suggesting that ENUM activities should solve DNS problems. > Or that DNSSEC would "sidetrack" trials. [And even if it did, surely > that's a matter for the people running those trials?] The text says > DNSSEC is "recommended" so trials can choose to experiment with it or > not. I think it would be foolish for a trial not do investigate DNSSEC > since (a) we know the DNS is not secure; (b) we must be able to > validate data in the 164.arpa tree or else E.164 falls apart; (c) > DNSSEC is the only game in town for validating the DNS. There is no > alternative. There's no choice between DNSSEC and something else. It's > DNSSEC or nothing. What do you suggest? > > I appreciate that selling ENUM is hard in these difficult times. Even > more so if DNSSEC is in there too. But the alternative of not doing > that is worse if the DNS gets spoofed. Ignoring the potential damage > that will undoubtedly cause is irresponsible. > > Richard> Before DNSSEC is implemented in ENUM I would like to see > Richard> it feasabely implemented somewhere else. > > If everyone takes that attitude, we get nowhere because it's always > somebody else's problem. ENUM will be an ideal place to experiment > with DNSSEC, mainly because there is no significant installed base, no > backwards compatibility issues and ENUM applications are still under > development so there should be engineering momentum for making those > things DNSSEC-aware. After all, we *know* that one day ENUM stuff will > have to be DNSSEC aware. > > There are other DNSSEC activities. RIPE NCC's DISI project for their > in-addr.arpa tree is the most visible. These are hampered by having an > installed base and backwards compatibility considerations. Neither of > these things are significant concerns in the virgin territory of > e164.arpa. > > Richard> So what is the reason to get in all this hassle with > Richard> DNSSEC in e164.arpa, as long as .net is not secure? > > Because if e164.arpa is secure -- and this can be done much more > easily than other parts of the name space -- it means we can at least > be sure that those lookups can be validated. We can start by being > certain that the NAPTR records you looked up for my phone number are > exactly what I put in the DNS. That alone has to be worthwhile, no? > Maybe these NAPTRs point only at tel: URIs, so if my DNS data is > signed, that has to be a Very Good Thing. You'll know for sure if that > tel: URI really does point at a premium rate number or not. If the > NAPTR records do point at SIP URIs, then I as the owner of some ENUM > delegation have the choice of putting the SIP server under a secure > part of the tree or not. For instance, I could duplicate the address > of Microsoft's SIP server with an entry in my signed zone under > 4.4.e164.arpa. So even if microsoft.com isn't signed, there could be a > signed NAPTR record for sip.microsoft.com, albeit one depending on a > duplicate A/AAAA record for that SIP server that lives at say > sip.microsoft.1.2.3.4.4.e164.arpa. It's ugly but could help until such > times as microsoft.com was signed and there was a chain of trust all > the way to the root. > > Richard> I am just wondering why the discussion stopped dead on > Richard> this list after the very valid question from Peter? > > Well in my case it's because I've been too busy with "real ENUM work" > :-) and not had time to respond yet. I think I've partially just done > that above. > > Richard> If you want to implement DNSSEC for ENUM, you have to > Richard> start at the root servers and in all domains, not in > Richard> e164.arpa only. There is no line to draw. > > In principle, yes. In practice no. Signing the root is fraught with > all sorts of political problems. Some of them were raised in Johan > Ihren's presentation in the DNS WG at RIPE last week. Signing > infrastructure stuff under .arpa is a good place to start. It doesn't > involve ICANN or the DoC. e164.arpa is an attractve choice for the > reasons I gave earlier. > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 7 14:14:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18653 for ; Fri, 7 Feb 2003 14:14:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17JLIf23992 for enum-archive@odin.ietf.org; Fri, 7 Feb 2003 14:21:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JL6p23984; Fri, 7 Feb 2003 14:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JJ0p23874 for ; Fri, 7 Feb 2003 14:19:00 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18559 for ; Fri, 7 Feb 2003 14:11:25 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA31416 for ; Fri, 7 Feb 2003 11:14:48 -0800 Message-Id: <5.2.0.9.2.20030207140903.01f24440@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Feb 2003 14:14:31 -0500 To: enum@ietf.org From: Richard Shockey In-Reply-To: <1044053805.12613.175.camel@blackdell.neonym.net> References: <5.2.0.9.2.20030131171354.04b20e80@shockey.us> <30794.1044047379@shell.nominum.com> <30794.1044047379@shell.nominum.com> <5.2.0.9.2.20030131171354.04b20e80@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Consensus on language DNSSEC Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , In the interest of moving things along I'm wondering if there is consensus on Mike's language here or would someone like to propose alternatives text to the security considerations... I want to repeat that we need to go through the document carefully since for any number of previously stated reasons we need to bring 2916bis to last call on or before SF. Are there any other outstanding issues we need to cover... Is it appropriate to discuss how applications should process the NAPTR records.. in what order 1. dont peek ahead at the URL 2. its still unclear to me the how order - preference should be processed >to this: > > As this system is built on top of DNS, one can not be sure that the > information one gets back from DNS is more secure than any other DNS > query. Being the only extant mechanism for securing DNS responses, > DNSSEC is the obvious solution for ensuring the security of ENUM > responses. However, at the time of publication of this document the > DNSSEC standard has not been finished. Until that time ENUM's use of > DNSSEC is merely recommended. Once DNSSEC is published as a Proposed > Standard, ENUM based systems SHOULD fully implement DNSSEC. At the > point at which DNSSEC becomes a Draft Standard, it MUST be > implemented by ENUM compliant systems. > > Additionally, due to the fact that some parts of the ENUM system may > be using DNSSEC before others, resolvers MUST be capable of handling > responses containing DNSSEC-related RR types even in cases where the > resolver or client application is unwilling or unable to perform > DNSSEC validation. > > >-MM > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 7 14:49:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19495 for ; Fri, 7 Feb 2003 14:49:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17JuBk25933 for enum-archive@odin.ietf.org; Fri, 7 Feb 2003 14:56:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ju9p25927; Fri, 7 Feb 2003 14:56:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Jtop25898 for ; Fri, 7 Feb 2003 14:55:50 -0500 Received: from rainier.illuminet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19470 for ; Fri, 7 Feb 2003 14:48:14 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [10.55.13.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id LAA25977; Fri, 7 Feb 2003 11:51:23 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id <1BKP27XW>; Fri, 7 Feb 2003 11:51:23 -0800 Message-ID: <90B62898D7B43B448D1A7297980A8C5F6CE4F8@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Consensus on language DNSSEC Date: Fri, 7 Feb 2003 11:51:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Mike's language provides flexibility by addressing the current concerns with DNSSEC readiness for deployment and the long term recommendation for security. Let's accept it and move on..... Kevin > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, February 07, 2003 1:15 PM > To: enum@ietf.org > Subject: [Enum] Consensus on language DNSSEC > > > > > In the interest of moving things along I'm wondering if there > is consensus > on Mike's language here or would someone like to propose > alternatives text > to the security considerations... > > > I want to repeat that we need to go through the document > carefully since > for any number of previously stated reasons we need to bring > 2916bis to > last call on or before SF. > > Are there any other outstanding issues we need to cover... > > Is it appropriate to discuss how applications should process > the NAPTR > records.. in what order > > 1. dont peek ahead at the URL > > 2. its still unclear to me the how order - preference should > be processed > > > > >to this: > > > > As this system is built on top of DNS, one can not be > sure that the > > information one gets back from DNS is more secure than > any other DNS > > query. Being the only extant mechanism for securing DNS > responses, > > DNSSEC is the obvious solution for ensuring the security of ENUM > > responses. However, at the time of publication of this > document the > > DNSSEC standard has not been finished. Until that time > ENUM's use of > > DNSSEC is merely recommended. Once DNSSEC is published > as a Proposed > > Standard, ENUM based systems SHOULD fully implement > DNSSEC. At the > > point at which DNSSEC becomes a Draft Standard, it MUST be > > implemented by ENUM compliant systems. > > > > Additionally, due to the fact that some parts of the > ENUM system may > > be using DNSSEC before others, resolvers MUST be capable > of handling > > responses containing DNSSEC-related RR types even in > cases where the > > resolver or client application is unwilling or unable to perform > > DNSSEC validation. > > > > > >-MM > > > >_______________________________________________ > >enum mailing list > >enum@ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Feb 9 21:40:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12656 for ; Sun, 9 Feb 2003 21:40:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A2mCr03974 for enum-archive@odin.ietf.org; Sun, 9 Feb 2003 21:48:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A2lsp03966; Sun, 9 Feb 2003 21:47:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A2jMp03914 for ; Sun, 9 Feb 2003 21:45:22 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12570 for ; Sun, 9 Feb 2003 21:36:39 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id SAA06191 for ; Sun, 9 Feb 2003 18:40:04 -0800 Message-Id: <5.2.0.9.2.20030209213748.01f5ff00@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 09 Feb 2003 21:39:50 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I'm ready to take requests for time in SF Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , who will have new documents ? revisions of the h323 and sip registrations ...? I doubt I will have a revision of the Privacy and Security document... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Feb 10 09:58:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11228 for ; Mon, 10 Feb 2003 09:58:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AF6mC20370 for enum-archive@odin.ietf.org; Mon, 10 Feb 2003 10:06:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AF6fp20362; Mon, 10 Feb 2003 10:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AF5ep20314 for ; Mon, 10 Feb 2003 10:05:40 -0500 Received: from rainier.illuminet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11142 for ; Mon, 10 Feb 2003 09:56:43 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [10.55.13.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA03651 for ; Mon, 10 Feb 2003 07:00:24 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id <1BKPJVN9>; Mon, 10 Feb 2003 07:00:24 -0800 Message-ID: <90B62898D7B43B448D1A7297980A8C5F6CE50B@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Date: Mon, 10 Feb 2003 07:00:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/related; boundary="----_=_NextPart_000_01C2D115.20A1ACA0"; type="multipart/alternative" Subject: [Enum] FW: VISIONng-Pulver Press Release ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2D115.20A1ACA0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D115.20A1ACA0" ------_=_NextPart_001_01C2D115.20A1ACA0 Content-Type: text/plain; charset="iso-8859-1" News on ENUM trial... -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Monday, February 10, 2003 2:59 AM To: enum-trials@ripe.net Cc: m.ermert@gmx.de Subject: FW: VISIONng-Pulver Press Release ENUM FYI Bild (Metafile) Contact: Carl Ford pulver.com Phone: +1.631.547.0800 Fax: +1.631.293.3996 Cell:+1.631.839.2626115 Broadhollow Road Suite 225 Melville, NY 11747 carl@pulver.com www.pulver.com/fwdVISIONng Press Release VISIONng expands Worldwide ENUM service to the states and beyond: The deployment of the International country code "87810" will be offered to VoIP customers around the world by Internet Telephony Service Providers. US demonstrations planned at Spring VON in San Jose (April 1-3). Sophia Antipolis, France, February 10th, 2003: VISIONng ( http://www.visionng.org) announced today that a US trial of ENUM, an Internet Standard which uses the Internet Domain Name System [DNS] to reconcile telephone numbers, will be deployed for use with the Global Country Code "87810". ENUM is a standard that can also be used for resolving requests to one universal phone number. Telephone numbers are based on ITU's E.164 country codes and therefore are considered national resources. National Regulatory Authorities must designate ENUM Tier 1 registries for their national phone numbers. ENUM is a IETF standard and this service will use the ITU/IETF agreed upon e164.arpa root as specified in RFC2916. The "87810" country code is administered as specified by ITU SG2. Essentially, ENUM allows phone numbers to be looked up the same way the web finds a domain name. Telesoft and pulver.com have announced their intention to offer ENUM capabilities to their users, expanding services beyond traditional service providers. Vincent Bergin Director of Telesoft, a service provider based in the UK stated that Telesoft will offer "87810" services to their International customers. "At Telesoft we see the opportunity to offer customers new telephony services regardless of their existing telecom provider or country boundaries. This will enable enterprises and their customers to benefit from a cost effective and unified global service. "In Austria we have conducted national and international trials in the last year", said Richard Stastny Chair of the Austrian ENUM trial platform ( http://enum.nic.at), and we have seen the benefits of a universal telephone number with Telekom Austria as ENUM Registrar". Under this scenario the "87810" ENUM entry is used for directing the call to the proper medium. Faxes, e-mail, Instant Messaging, and all forms of telecommunication can be managed by this single powerful tool. An affiliated company to pulver.com's Free World Dial-up service will become an ENUM registrar enabling Free World Dialup (FWD) participants to maintain an ENUM entry that will enable a universal service. The use of the "87810" can also be used for vanity numbers, particularly for people who want to associate their Voice over IP (VoIP) gateways at home to their existing United States "1+" phone numbers. The test plan calls for pulver.com's Free World Dialup community to be the first one offered this experimental service in the US. "FWD is an open invitation to anyone with broadband Internet access to experience the great quality available today worldwide using broadband Internet Telephony", said Jeff Pulver, recognized Guru of the Voice over Internet Protocol (VoIP) Industry. "By allowing FWD participants to take an "87810" country code assignment we are making a statement that the PSTN and the Internet are global assets. The backbone of the Internet has made it possible for me to communicate with people just about anywhere in the world, and people should be able to reach me regardless of my physical geographic location. On the Internet with Free World Dialup, you can call a person, not a location. Services like Vonage, enable subscribers to use numbers from the North American Numbering Plan with area codes from the different parts of the US regardless of their location. "87810" is a global numbering resource, so the concept of area code is no longer relevant. At the Spring 2003 VON conference ( http://www.von.com ) in San Jose April 1-3, Telekom Austria and Free World Dialup will show a global number that is not using "borrowed" numbers from existing number pool allocations, but with the use of ENUM, the ability for Internet Telephony finally to be a peer to the traditional telephone line." "ENUM is much more than a single phone number; it makes it possible to truly marry Internet and PSTN signaling for the purpose of stating preferred communication media. According to Harald Hauser, Vice-Chair of VISIONng the value of ENUM is now being realized and it is getting considerable traction throughout the industry. Contrary to concerns about ENUM will be used to invade privacy, ENUM as delivered by the VISIONng members, allows the end user to have more control of the when where and how of communication. For example, I can set in place my preferences for family to be able to see my presence on Instant Messaging, friends to leave messages on my private e-mail and coworkers to reach me on my cell. I can even give a method of override via SMS to people who need to reach me in emergencies", said Herwart Wermescher chairman of VISIONng, and Solution Leader for BearingPoint VoIP. Carl Ford/Jeff Pulver FWD 115 Broadhollow Road Suite 225 Melville, NY 11747 Phone +1.631.547.0800 Fax: +1.631.293.3996 Mobile: +1.631.839.2626 mailto:carl@pulver.com www.pulver.com Herwart Wermescher Chairman VISIONng BearingPoint Solution Leader INFONOVA Solutions Phone +43 316 8003 1101 Mobile +43 664 25 65 180 Fax +43 316 8003 1480 mailto:herwart.wermescher@infonova.com www.bearingpoint.com Harald Hauser Vicechair VISIONng Telcordia 444 Hoes Lane RRC-4D226, Piscataway, New Jersey 08854 mailto:hhauser@telcordia.com www.telcordia.com For Release 1 p.m. GMT, February 10, 2003 Bild (Metafile) Bild (Metafile) Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at ------_=_NextPart_001_01C2D115.20A1ACA0 Content-Type: text/html; charset="iso-8859-1" FW: VISIONng-Pulver Press Release ENUM
News on ENUM trial...
 
-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
Sent: Monday, February 10, 2003 2:59 AM
To: enum-trials@ripe.net
Cc: m.ermert@gmx.de
Subject: FW: VISIONng-Pulver Press Release ENUM

FYI

       
       
Bild (Metafile)       
Contact: Carl Ford
pulver.com
Phone: +1.631.547.0800
Fax: +1.631.293.3996

Cell:+1.631.839.2626115 Broadhollow Road
Suite 225
Melville, NY 11747
carl@pulver.com
www.pulver.com/fwdVISIONng
 
Press Release

VISIONng expands Worldwide ENUM service to the states and beyond: The deployment of the International country code “87810” will be offered to VoIP customers around the world by Internet Telephony Service Providers.


US demonstrations planned at Spring VON in San Jose (April 1-3).
Sophia Antipolis, France, February 10th, 2003: VISIONng (http://www.visionng.org) announced today that a US trial of ENUM, an Internet Standard which uses the Internet Domain Name System [DNS] to reconcile telephone numbers, will be deployed for use with the Global Country Code “87810”.  ENUM is a standard that can also be used for resolving requests to one universal phone number.  Telephone numbers are based on ITU’s E.164 country codes and therefore are considered national resources.  National Regulatory Authorities must designate ENUM Tier 1 registries for their national phone numbers.  ENUM is a IETF standard and this service will use the ITU/IETF agreed upon e164.arpa root as specified in RFC2916.  The “87810” country code is administered as specified by ITU SG2.  Essentially, ENUM allows phone numbers to be looked up the same way the web finds a domain name.

Telesoft and pulver.com have announced their intention to offer ENUM capabilities to their users, expanding services beyond traditional service providers.

Vincent Bergin Director of Telesoft, a service provider based in the UK stated that Telesoft will offer “87810” services to their International customers.  “At Telesoft we see the opportunity to offer customers new telephony services regardless of their existing telecom provider or country boundaries.  This will enable enterprises and their customers to benefit from a cost effective and unified global service.

“In Austria we have conducted national and international trials in the last year”, said Richard Stastny Chair of the Austrian ENUM trial platform (http://enum.nic.at), and we have seen the benefits of a universal telephone number with Telekom Austria as ENUM Registrar”.  Under this scenario the “87810” ENUM entry is used for directing the call to the proper medium.  Faxes, e-mail, Instant Messaging, and all forms of telecommunication can be managed by this single powerful tool. 

An affiliated company to pulver.com’s Free World Dial-up service will become an ENUM registrar enabling Free World Dialup (FWD) participants to maintain an ENUM entry that will enable a universal service.  The use of the “87810” can also be used for vanity numbers, particularly for people who want to associate their Voice over IP (VoIP) gateways at home to their existing United States “1+” phone numbers. 

The test plan calls for pulver.com’s Free World Dialup community to be the first one offered this experimental service in the US.  “FWD is an open invitation to anyone with broadband Internet access to experience the great quality available today worldwide using broadband Internet Telephony”, said Jeff Pulver, recognized Guru of the Voice over Internet Protocol (VoIP) Industry. 

"By allowing FWD participants to take an "87810" country code assignment we are making a statement that the PSTN and the Internet are global assets.  The backbone of the Internet has made it possible for me to communicate with people just about anywhere in the world, and people should be able to reach me regardless of my physical geographic location. On the Internet with Free World Dialup, you can call a person,
not a location. Services like Vonage, enable subscribers to use numbers from the North American Numbering Plan with area codes from the different parts of the US regardless of their location.  "87810" is a global numbering resource, so the concept of area code is no longer relevant.

At the Spring 2003 VON conference ( http://www.von.com ) in San Jose April 1-3, Telekom Austria and Free World Dialup will show a global number that is not using "borrowed" numbers from existing number pool allocations, but with the use of ENUM, the ability for Internet Telephony finally to be a peer to the traditional telephone line."

“ENUM is much more than a single phone number; it makes it possible to truly marry Internet and PSTN signaling for the purpose of stating preferred communication media.

According to Harald Hauser, Vice-Chair of VISIONng the value of ENUM is now being realized and it is getting considerable traction throughout the industry.

Contrary to concerns about ENUM will be used to invade privacy, ENUM as delivered by the VISIONng members, allows the end user to have more control of the when where and how of communication.  For example, I can set in place my preferences for family to be able to see my presence on Instant Messaging, friends to leave messages on my private e-mail and coworkers to reach me on my cell.  I can even give a method of override via SMS to people who need to reach me in emergencies”, said Herwart Wermescher chairman of VISIONng, and Solution Leader for BearingPoint VoIP.

Carl Ford/Jeff Pulver
FWD
115 Broadhollow Road
Suite 225
Melville, NY 11747
Phone +1.631.547.0800
Fax: +1.631.293.3996
Mobile: +1.631.839.2626
mailto:carl@pulver.com
www.pulver.com

Herwart Wermescher 
Chairman VISIONng
BearingPoint 
Solution Leader INFONOVA Solutions
Phone +43 316 8003 1101
Mobile +43 664 25 65 180 
Fax +43 316 8003 1480
mailto:herwart.wermescher@infonova.com
www.bearingpoint.com

Harald Hauser
Vicechair VISIONng
Telcordia
444 Hoes Lane
RRC-4D226,
Piscataway, New Jersey 08854
mailto:hhauser@telcordia.com
www.telcordia.com


 For Release 1 p.m. GMT, February 10, 2003
       
Bild (Metafile)       

       
Bild (Metafile)       


Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
mailto:richard.stastny@oefeg.at

------_=_NextPart_001_01C2D115.20A1ACA0-- ------_=_NextPart_000_01C2D115.20A1ACA0 Content-Type: image/bmp; name="ole0.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ole0.bmp" Content-Description: Bild (Metafile) Content-Location: No%20AttachName Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Qk0+AAAAAAAAADoAAAAoAAAAAQAAAAEAAAABAAEAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA//// AAAAAAA= ------_=_NextPart_000_01C2D115.20A1ACA0 Content-Type: image/bmp; name="ole1.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ole1.bmp" Content-Description: Bild (Metafile) Content-Location: No%20AttachName-1 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Qk0+AAAAAAAAADoAAAAoAAAAAQAAAAEAAAABAAEAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA//// AAAAAAA= ------_=_NextPart_000_01C2D115.20A1ACA0 Content-Type: image/bmp; name="ole2.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ole2.bmp" Content-Description: Bild (Metafile) Content-Location: No%20AttachName-2 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Qk0+AAAAAAAAADoAAAAoAAAAAQAAAAEAAAABAAEAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA//// AAAAAAA= ------_=_NextPart_000_01C2D115.20A1ACA0-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Feb 10 10:12:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11703 for ; Mon, 10 Feb 2003 10:12:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AFL7k21565 for enum-archive@odin.ietf.org; Mon, 10 Feb 2003 10:21:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFL6p21560; Mon, 10 Feb 2003 10:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFK2p21516 for ; Mon, 10 Feb 2003 10:20:02 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11658 for ; Mon, 10 Feb 2003 10:11:04 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA29960 for ; Mon, 10 Feb 2003 07:14:29 -0800 Message-Id: <5.2.0.9.2.20030210100803.01c81510@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Feb 2003 10:09:03 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] A good reminder of what IETF WG Meetings are about Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I've sent this out before but its a useful reminder as we approach SF. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be skechted, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientented toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 12 09:25:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03475 for ; Wed, 12 Feb 2003 09:25:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CEYQR19240 for enum-archive@odin.ietf.org; Wed, 12 Feb 2003 09:34:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEYAp19231; Wed, 12 Feb 2003 09:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEVQp19118 for ; Wed, 12 Feb 2003 09:31:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03347; Wed, 12 Feb 2003 09:21:30 -0500 (EST) Message-Id: <200302121421.JAA03347@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 12 Feb 2003 09:21:30 -0500 Subject: [Enum] I-D ACTION:draft-brandner-enumservice-msg-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration for enumservices of group messages Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enumservice-msg-00.txt Pages : 0 Date : 2003-2-11 This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-msg-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brandner-enumservice-msg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brandner-enumservice-msg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-11141237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enumservice-msg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enumservice-msg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-11141237.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 12 21:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22258 for ; Wed, 12 Feb 2003 21:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D38pr08561 for enum-archive@odin.ietf.org; Wed, 12 Feb 2003 22:08:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D38jp08556; Wed, 12 Feb 2003 22:08:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D374p07968 for ; Wed, 12 Feb 2003 22:07:04 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22215 for ; Wed, 12 Feb 2003 21:56:52 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA20809 for ; Wed, 12 Feb 2003 19:00:20 -0800 Message-Id: <5.2.0.9.2.20030212215718.02021588@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 22:00:26 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FYI - The United Stated Government backs global participation in ENUM within e164.arpa Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , the press release http://www.ntia.doc.gov/ntiahome/press/2003/enumpr_02122003.htm the letter http://www.ntia.doc.gov/ntiahome/ntiageneral/enum/enum_02122003.htm >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 13 10:28:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15759 for ; Thu, 13 Feb 2003 10:28:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFcPF28851 for enum-archive@odin.ietf.org; Thu, 13 Feb 2003 10:38:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFc8p28828; Thu, 13 Feb 2003 10:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFaYp28039 for ; Thu, 13 Feb 2003 10:36:34 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15654 for ; Thu, 13 Feb 2003 10:26:07 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 13 Feb 2003 16:33:29 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DEF65@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] FYI - The United Stated Government backs global participation in ENUM within e164.arpa Thread-Index: AcLTDXhrT8hT7x3ARmSdQ4ayzaVQbAAZxH3f From: "Stastny Richard" To: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h1DFaYp28040 Subject: [Enum] FYI - The United Stated Government backs global participation in ENUM within e164.arpa Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rich, Thanks for this important information. So finally the US is doing something to "maintain its world leadership in technology policy." ;-) Richard -----UrsprĂ¼ngliche Nachricht----- Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Do 13.02.2003 04:00 An: enum@ietf.org Cc: Betreff: [Enum] FYI - The United Stated Government backs global participation in ENUM within e164.arpa the press release http://www.ntia.doc.gov/ntiahome/press/2003/enumpr_02122003.htm the letter http://www.ntia.doc.gov/ntiahome/ntiageneral/enum/enum_02122003.htm >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 14 12:13:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27658 for ; Fri, 14 Feb 2003 12:13:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EHHKi08657 for enum-archive@odin.ietf.org; Fri, 14 Feb 2003 12:17:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EHH5p08651; Fri, 14 Feb 2003 12:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EHB3p08434 for ; Fri, 14 Feb 2003 12:11:03 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27525 for ; Fri, 14 Feb 2003 12:06:48 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA09612 for ; Fri, 14 Feb 2003 09:10:17 -0800 Message-Id: <5.2.0.9.2.20030214114537.0297a988@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 12:10:19 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FYI : FCC Chairman Powell's Letter to State Dept's David Gross Backs Linkage of Internet Services with Telephone Numbers Through U.S. Implementation of ENUM. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , http://www.fcc.gov/commissioners/powell/gross_enum_letter-021303.pdf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 06:19:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18815 for ; Wed, 19 Feb 2003 06:19:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBPaI31276 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 06:25:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBPIp31250; Wed, 19 Feb 2003 06:25:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBNCp31140 for ; Wed, 19 Feb 2003 06:23:12 -0500 Received: from paf.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18746 for ; Wed, 19 Feb 2003 06:16:39 -0500 (EST) Received: by paf.se (CommuniGate Pro PIPE 4.0.5) with PIPE id 941719; Wed, 19 Feb 2003 12:20:24 +0100 Received: from [62.119.82.130] (account paf HELO cisco.com) by paf.se (CommuniGate Pro SMTP 4.0.5) with ESMTP id 941711; Wed, 19 Feb 2003 12:20:11 +0100 Date: Wed, 19 Feb 2003 08:36:50 +0100 Subject: Re: [Enum] TEL URL enumservice registration document Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: enum@ietf.org To: Richard Shockey From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5.2.0.9.2.20030131132633.0494c670@popd.ix.netcom.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,A_FROM_IN_AUTO_WLIST,RCVD_IN_ORBZ version=2.01 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jan 31, 2003, at 19:40 Europe/Stockholm, Richard Shockey wrote: > It was recently pointed out to me privately that we have no example in > 2916bis of a TEL URL. The question was posed .."are we going to > allow termination to non IP endpoints?" Another thing, as Richard wrote, the answer to this question is obviously "yes", but it also scares me that the question is asked in the first place. I thought it very clearly said that (a) any URI scheme can be used (b) enum services need to be registered via specific explicit documents. Suggestions to changes to the document so it is clearer is appreciated. Silence is taken as "the document is fine as is". Richard has as wg chair told me as editor of the document that he want one last version now, before Feb 24, so we can get 2916bis out the door. It is needed, and I agree with him. We can not live with RFC 2916 any longer. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 06:19:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18827 for ; Wed, 19 Feb 2003 06:19:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBPc031304 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 06:25:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBPcp31299; Wed, 19 Feb 2003 06:25:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBNGp31148 for ; Wed, 19 Feb 2003 06:23:16 -0500 Received: from paf.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18748 for ; Wed, 19 Feb 2003 06:16:40 -0500 (EST) Received: by paf.se (CommuniGate Pro PIPE 4.0.5) with PIPE id 941723; Wed, 19 Feb 2003 12:20:24 +0100 Received: from [62.119.82.130] (account paf HELO cisco.com) by paf.se (CommuniGate Pro SMTP 4.0.5) with ESMTP id 941714; Wed, 19 Feb 2003 12:20:15 +0100 Date: Wed, 19 Feb 2003 08:59:39 +0100 Subject: Re: [Enum] On the question of DNSSEC and recommended Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Stastny Richard , Jim Reid , enum@ietf.org To: Michael Mealling From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1044551438.4605.147.camel@blackdell.neonym.net> Message-Id: <18BB313D-43E0-11D7-828E-0003934B2128@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,A_FROM_IN_AUTO_WLIST,RCVD_IN_ORBZ version=2.01 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am a bit nervous of talking too much of how and when DNSSEC is to be applied. I agree completely with what Michael said from a technical standpoint, but, DNSSEC can unfortunately not be deployed not only before the RFC's are ready, but also not before the key-management/distribution issues are resolved. Just because nothing of this is done yet, I rather have a text which say something which specify the functionality requirement people are after in 2916bis. What do you all say about something like the following: As ENUM is using DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one get back is authentic. In the IETF, work is going on with DNSSEC which is a mechanism where data integrity can be verified by the querying party, so the client can be sure the data is originating from an authoritative source. ENUM services deployed on the global Internet is expected to be a popular target for various kind of attacks, and attacking the DNS is one way of attacking the ENUM service itself. Because of this, an ENUM service deployed SHOULD include mechanisms which implement security services like DNSSEC do, verification of authenticity of the data. This include not only the ENUM lookup itself, but also the various records needed for the services to be useful (for example MX, SRV and A records). Finally, as an ENUM service according to the previous paragraph is expected to use DNSSEC when defined by the IETF, software which implement ENUM MUST be prepared on DNSSEC being used, which include large responses, requirement for EDNS0 signaling etc. Note that SHOULD and MUST is defined in RFC 2119. I am not as afraid of misinterpretation of the SHOULD. The difference I try to make between the above and what Michael wrote are mainly 2: (1) No MUST for DNSSEC, because I don't see we can write MUST together with a 2nd requirement which is impossible to measure today. (2) I try to point out that IF other mechanisms are invented before DNSSEC is deployed, which implement the same kind of authenticity, that is possibly a solution which can be used. I don't see one today, but, who knows? It is also the case that when we have had our test beds, it might be the case that we see that the _services_ need to be so secured in all different kinds of way that security on the ENUM lookup doesn't add anything. It might be too complicated to have security on the ENUM level. Yes, one can inject a ddos attack by faking DNS responses, but even if the ENUM DNS queries/responses are signed I am sure we might see other ways of breaking the DNS lookup by attacking the protocol itself (i.e. making sure _no_ response is reaching the querying party). Requiring DNSSEC for the ENUM lookup make people believe the rest of the system is secure, the SRV and A records used for SIP, MX+A for SMTP, the actual protocol (SIP, SMTP etc) used for the exchange of information. Security is not something that can be applied at one location, and the Internet will be secure. That said, of course ENUM should (as any protocol) have appropriate security. paf On torsdag, feb 6, 2003, at 18:10 Europe/Stockholm, Michael Mealling wrote: > On Thu, 2003-02-06 at 07:14, Stastny Richard wrote: >> The major problem I have with your proposal is to see the MUSTs NOW in >> RFC2916bis: >> >> "At the >> point at which DNSSEC becomes a Draft Standard, it MUST be >> implemented by ENUM compliant systems." >> >> Some may get the idea to prevent DNSSEC to get a Draft Standard ;-) > > The point of the MUST being at Draft instead of Proposed is that once > that level of standardization is obtained with DNSSEC it probably > should > be made a MUST for all new protocols anyway. The MUST isn't there for > Proposed. There is an ___extremely___ important difference. If/When > DNSSEC gets to Proposed I'm pretty sure the IETF will feel very > strongly > that you will have to have an extremely good reason to not require > DNSSEC. > >> I also have problems with this: >> >> "Additionally, due to the fact that some parts of the ENUM system >> may >> >> be using DNSSEC before others, resolvers MUST be capable of >> handling >> responses containing DNSSEC-related RR types even in cases where >> the >> resolver or client application is unwilling or unable to perform >> DNSSEC validation." >> >> See the comments from Lawrence. I have a problem here because I do not >> yet fully understand the implications of this. I have learned >> during the discussions on the enumservices that the clients >> out there may be so dumb that they cannot evaluate the regexp of all >> NAPTRs first, >> so they have to select the NAPTR only with the enumservice, but the >> same >> dumb clients (example was always mobile phones) now MUST be fully >> capable >> of handling DNSSEC. >> >> I am just wondering. > > The point here is that there have been resolvers that choked on unkown > RR types. This is a violation of the DNS standard itself and simply a > bad implementation. Being able to not fail when presented with an > unknown RR type will not add any size or complexity to a 'dumb' device. > Heck, there are RFID tags that have tiny built in cameras for taking > pictures and transmitting them. I can't imagine what kind of > requirements a device might have that it can't handle the minimum of > not > barfing when presented with DNSSEC RRs... > > Again, this requirement doesn't say you have to implement DNSSEC, you > just have to not die if you see them in your responses... > > -MM > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 07:11:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18831 for ; Wed, 19 Feb 2003 06:19:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBPd531333 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 06:25:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBPdp31328; Wed, 19 Feb 2003 06:25:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBNPp31158 for ; Wed, 19 Feb 2003 06:23:25 -0500 Received: from paf.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18756 for ; Wed, 19 Feb 2003 06:16:51 -0500 (EST) Received: by paf.se (CommuniGate Pro PIPE 4.0.5) with PIPE id 941729; Wed, 19 Feb 2003 12:20:39 +0100 Received: from [62.119.82.130] (account paf HELO cisco.com) by paf.se (CommuniGate Pro SMTP 4.0.5) with ESMTP id 941717; Wed, 19 Feb 2003 12:20:21 +0100 Date: Wed, 19 Feb 2003 12:19:57 +0100 Subject: Re: [Enum] TEL URL enumservice registration document Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: enum@ietf.org To: Richard Shockey From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5.2.0.9.2.20030131132633.0494c670@popd.ix.netcom.com> Message-Id: <13B45FBC-43FC-11D7-828E-0003934B2128@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,A_FROM_IN_AUTO_WLIST,RCVD_IN_ORBZ version=2.01 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jan 31, 2003, at 19:40 Europe/Stockholm, Richard Shockey wrote: > The answer to that obviously yes but I believe the authors wanted to > keep the examples in 2916bis to a minimum as not to create undue > confusion. ...and only include examples which are (a) sent in from people which request them (b) having strong support in the community. What has happened with examples in RFC 2916 is that people read the examples and not the text in the document. That together with people not understanding the word "example" has created problems. I rather have a (boring) document specifying the minimum needed for implementation, and then later a different document on "practices" which can explain how the standard is used. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 09:42:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26178 for ; Wed, 19 Feb 2003 09:42:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEmGH15465 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 09:48:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEm8p15457; Wed, 19 Feb 2003 09:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEkIp15335 for ; Wed, 19 Feb 2003 09:46:18 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26134 for ; Wed, 19 Feb 2003 09:39:40 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 18 Feb 2003 20:22:26 -0500 Subject: Re: [Enum] On the question of DNSSEC and recommended From: Michael Mealling To: "Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?=" Cc: Stastny Richard , Jim Reid , enum@ietf.org, paf@paf.se In-Reply-To: <18BB313D-43E0-11D7-828E-0003934B2128@cisco.com> References: <18BB313D-43E0-11D7-828E-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Harriman Heavy Industries, Inc. Message-Id: <1045665563.23877.392.camel@blackdell.neonym.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Feb 2003 09:39:23 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Wed, 2003-02-19 at 02:59, Patrik Fältström wrote: > I am a bit nervous of talking too much of how and when DNSSEC is to be > applied. I agree completely with what Michael said from a technical > standpoint, but, DNSSEC can unfortunately not be deployed not only > before the RFC's are ready, but also not before the > key-management/distribution issues are resolved. Which is why I didn't make it required until the Draft Standard point because I figured it would've had to solve those problems in order to get to that point. But that is possibly a false assumption on my part. > What do you all say about something like the following: > > As ENUM is using DNS, which in its current form is an insecure > protocol, there is no mechanism for ensuring that the data one > get back is authentic. In the IETF, work is going on with DNSSEC > which is a mechanism where data integrity can be verified by > the querying party, so the client can be sure the data is > originating from an authoritative source. > > ENUM services deployed on the global Internet is expected to be > a popular target for various kind of attacks, and attacking the > DNS is one way of attacking the ENUM service itself. > > Because of this, an ENUM service deployed SHOULD include mechanisms > which implement security services like DNSSEC do, verification > of authenticity of the data. This include not only the ENUM > lookup itself, but also the various records needed for the > services to be useful (for example MX, SRV and A records). > > Finally, as an ENUM service according to the previous paragraph > is expected to use DNSSEC when defined by the IETF, software > which implement ENUM MUST be prepared on DNSSEC being used, which > include large responses, requirement for EDNS0 signaling etc. I'm fine with it. I'd prefer it to be stronger simply because I've seen large numbers of people assume that everything that isn't a 'MUST' can be safely ignored. > (1) No MUST for DNSSEC, because I don't see we can write MUST together > with a 2nd requirement which is impossible to measure today. Yea, I can see that. I just wish we could say it more strongly than you have. But I guess putting "really, really SHOULD" isn't really proper. > (2) I try to point out that IF other mechanisms are invented before > DNSSEC is deployed, which implement the same kind of authenticity, that > is possibly a solution which can be used. I don't see one today, but, > who knows? If that becomes the case then large numbers of documents have to change, not just ENUM.... > It is also the case that when we have had our test beds, it might be > the case that we see that the _services_ need to be so secured in all > different kinds of way that security on the ENUM lookup doesn't add > anything. It might be too complicated to have security on the ENUM > level. Yes, one can inject a ddos attack by faking DNS responses, but > even if the ENUM DNS queries/responses are signed I am sure we might > see other ways of breaking the DNS lookup by attacking the protocol > itself (i.e. making sure _no_ response is reaching the querying party). > > Requiring DNSSEC for the ENUM lookup make people believe the rest of > the system is secure, the SRV and A records used for SIP, MX+A for > SMTP, the actual protocol (SIP, SMTP etc) used for the exchange of > information. Sure, but conversely, people will think that if DNSSEC isn't required then there isn't sufficient need for ENUM to be secured. > Security is not something that can be applied at one location, and the > Internet will be secure. That said, of course ENUM should (as any > protocol) have appropriate security. Completely agree. I'm fine with your language but I think in the future as soon as DNSSEC is 'ready' that the IAB and IESG should make some statement similar to what they did for Unicode and 7bit ascii. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 11:51:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01254 for ; Wed, 19 Feb 2003 11:51:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGvWt25542 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 11:57:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGvRp25533; Wed, 19 Feb 2003 11:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGu2p25472 for ; Wed, 19 Feb 2003 11:56:02 -0500 Received: from sheridan.swishmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01200 for ; Wed, 19 Feb 2003 11:49:21 -0500 (EST) Received: (qmail 74073 invoked by uid 89); 19 Feb 2003 16:53:11 -0000 Received: from unknown (HELO RWALTER) (65.203.166.45) by sheridan.swishmail.com with SMTP; 19 Feb 2003 16:53:11 -0000 From: "Robert H. Walter" To: Date: Wed, 19 Feb 2003 11:53:11 -0500 Message-ID: <001e01c2d837$62e215e0$2da6cb41@netnumber.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Enum] Feedback on ENUM Service Registration for MMS Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rudolf, Lawrence and Richard, Please consider modifying section 5.4 MMS Service Registration to include the following subtypes and URI schemes as prescribed by 3GPP TS 23.140 V6.0.0 (2002-12) Multimedia Messaging Service (MMS): Subtypes: "smtp", "http" URI Schemes: "mms" Valid NAPTR service field examples for MMS would include: "E2U+mms" - Indicates MMS service availability with NO advertised protocol support. "E2U+mms:smtp" - Indicates MMS service availability with advertised SMTP protocol support. "E2U+mms:http" - Indicates MMS service availability with advertised HTTP protocol support. Regards, Bob Walter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 13:25:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04020 for ; Wed, 19 Feb 2003 13:25:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JIVT032084 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 13:31:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JIVNp32078; Wed, 19 Feb 2003 13:31:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JITYp32012 for ; Wed, 19 Feb 2003 13:29:34 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03954 for ; Wed, 19 Feb 2003 13:22:51 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA02191; Wed, 19 Feb 2003 10:25:08 -0800 Message-Id: <5.2.0.9.2.20030219131934.01613e18@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Feb 2003 13:25:16 -0500 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Richard Shockey Subject: Re: [Enum] TEL URL enumservice registration document Cc: enum@ietf.org In-Reply-To: References: <5.2.0.9.2.20030131132633.0494c670@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > >I thought it very clearly said that (a) any URI scheme can be used (b) >enum services need to be registered via specific explicit documents. And the procedure for those documents are outlined in 2916bis >Suggestions to changes to the document so it is clearer is appreciated. >Silence is taken as "the document is fine as is". Yes.. as the non author chair this is exactly how I will interpret rough consensus in determining whether to request last call. The only remaining issue is the language in the security considerations on what level of DNSSEC support should be implemented and when based on the status of the relevant DNSSEC documents and reports on experimental implementations. >Richard has as wg chair told me as editor of the document that he want one >last version now, before Feb 24, so we can get 2916bis out the door. > >It is needed, and I agree with him. We can not live with RFC 2916 any longer. Yes thank you for pointing this out again ... it is my intention to request last call on 2916bis ..after we see the 04 revisions ..barring no problems ...at the earliest possible date.. > paf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 17:39:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11406 for ; Wed, 19 Feb 2003 17:39:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JMjm716444 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 17:45:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMjjp16437; Wed, 19 Feb 2003 17:45:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMiep16411 for ; Wed, 19 Feb 2003 17:44:40 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11366; Wed, 19 Feb 2003 17:37:51 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1JMffD15315; Wed, 19 Feb 2003 14:41:41 -0800 (PST) Message-Id: <200302192241.h1JMffD15315@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, enum@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 19 Feb 2003 14:41:41 -0800 Subject: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3482 Title: Number Portability in the Global Switched Telephone Network (GSTN): An Overview Author(s): M. Foster, T. McGarry, J. Yu Status: Informational Date: February 2003 Mailbox: mark.foster@neustar.biz, tom.mcgarry@neustar.biz, james.yu@neustar.biz Pages: 30 Characters: 78552 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This document is a product of the Telephone Number Mapping Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030219143953.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3482 --OtherAccess Content-Type: Message/External-body; name="rfc3482.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030219143953.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 19 23:10:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18590 for ; Wed, 19 Feb 2003 23:10:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K4Gc101366 for enum-archive@odin.ietf.org; Wed, 19 Feb 2003 23:16:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K4GZp01359; Wed, 19 Feb 2003 23:16:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K4FVp01338 for ; Wed, 19 Feb 2003 23:15:31 -0500 Received: from mclean.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18580 for ; Wed, 19 Feb 2003 23:08:36 -0500 (EST) Received: from dialup-64.156.76.92.dial1.dallas1.level3.net ([64.156.76.92] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18li4I-0007Lw-00; Wed, 19 Feb 2003 23:12:19 -0500 Message-ID: <3E5471EB.96546E1E@ix.netcom.com> Date: Wed, 19 Feb 2003 22:12:59 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: rfc-editor@rfc-editor.org CC: enum@ietf.org, mark.foster@neustar.biz, tom.mcgarry@neustar.biz, james.yu@neustar.biz, Jeff Neuman Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <200302192241.h1JMffD15315@gamma.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RFC Editor and all, Looks an awful lot like a Nuestar/IEGF document/RFC to me. Has Nuestar taken over a percentage of the IETF recently? rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > RFC 3482 > > Title: Number Portability in the Global Switched > Telephone Network (GSTN): An Overview > Author(s): M. Foster, T. McGarry, J. Yu > Status: Informational > Date: February 2003 > Mailbox: mark.foster@neustar.biz, tom.mcgarry@neustar.biz, > james.yu@neustar.biz > Pages: 30 > Characters: 78552 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > This document provides an overview of E.164 telephone number > portability (NP) in the Global Switched Telephone Network > (GSTN). > > NP is a regulatory imperative seeking to liberalize local > telephony service competition, by enabling end-users to retain > telephone numbers while changing service providers. NP changes the > fundamental nature of a dialed E.164 number from a hierarchical > physical routing address to a virtual address, thereby requiring the > transparent translation of the later to the former. In addition, > there are various regulatory constraints that establish relevant > parameters for NP implementation, most of which are not network > technology specific. Consequently, the implementation of NP > behavior consistent with applicable regulatory constraints, as well > as the need for interoperation with the existing GSTN NP > implementations, are relevant topics for numerous areas of IP > telephony works-in-progress with the IETF. > > This document is a product of the Telephone Number Mapping Working > Group of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 04:14:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04930 for ; Thu, 20 Feb 2003 04:14:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9Kss29374 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 04:20:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9Kkp29360; Thu, 20 Feb 2003 04:20:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9Frp29180 for ; Thu, 20 Feb 2003 04:15:53 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04792 for ; Thu, 20 Feb 2003 04:08:51 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 20 Feb 2003 10:16:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620E9DAF@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Thread-Index: AcLYmQNFQ0JWVOrdTMWNOint0UM3FwAJt+TA From: "Stastny Richard" To: "Jeff Williams" , Cc: , , , , "Jeff Neuman" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1K9Frp29181 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jeff, I do not read this. So what is your problem with this informational document? I there anything wrong in it? Richard > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Thursday, February 20, 2003 7:13 AM > To: rfc-editor@rfc-editor.org > Cc: enum@ietf.org; mark.foster@neustar.biz; > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > Subject: Re: [Enum] RFC 3482 on Number Portability in the > Global Switched Telephone Network (GSTN): An Overview > > > RFC Editor and all, > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > Has Nuestar taken over a percentage of the IETF recently? > > rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > RFC 3482 > > > > Title: Number Portability in the Global Switched > > Telephone Network (GSTN): An Overview > > Author(s): M. Foster, T. McGarry, J. Yu > > Status: Informational > > Date: February 2003 > > Mailbox: mark.foster@neustar.biz, > tom.mcgarry@neustar.biz, > > james.yu@neustar.biz > > Pages: 30 > > Characters: 78552 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > This document provides an overview of E.164 telephone number > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > NP is a regulatory imperative seeking to liberalize local telephony > > service competition, by enabling end-users to retain > telephone numbers > > while changing service providers. NP changes the > fundamental nature > > of a dialed E.164 number from a hierarchical physical > routing address > > to a virtual address, thereby requiring the transparent > translation of > > the later to the former. In addition, there are various regulatory > > constraints that establish relevant parameters for NP > implementation, > > most of which are not network technology specific. > Consequently, the > > implementation of NP behavior consistent with applicable regulatory > > constraints, as well as the need for interoperation with > the existing > > GSTN NP implementations, are relevant topics for numerous > areas of IP > > telephony works-in-progress with the IETF. > > > > This document is a product of the Telephone Number Mapping Working > > Group of the IETF. > > > > This memo provides information for the Internet community. It does > > not specify an Internet standard of any kind. Distribution of this > > memo is unlimited > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > Requests to be added to or deleted from the IETF distribution list > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or > > deleted from the RFC-DIST distribution list should be sent to > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > by sending > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > > > To: rfc-info@RFC-EDITOR.ORG > > Subject: getting rfcs > > > > help: ways_to_get_rfcs > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > for unlimited distribution.echo Submissions for Requests > for Comments > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > consult RFC 2223, > > Instructions to RFC Authors, for further information. > > > > Joyce K. Reynolds and Sandy Ginoza > > USC/Information Sciences Institute > > > > ... > > > > Below is the data which will enable a MIME compliant Mail Reader > > implementation to automatically retrieve the ASCII version of the > > RFCs. > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > strong!) > ================================================================ > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > Information Network Eng. Group. INEG. INC. E-Mail > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 05:00:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05891 for ; Thu, 20 Feb 2003 04:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KA5Fc31597 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 05:05:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KA3Cp31501; Thu, 20 Feb 2003 05:03:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9vXp31370 for ; Thu, 20 Feb 2003 04:57:33 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05724 for ; Thu, 20 Feb 2003 04:50:31 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1J2JRK1P>; Thu, 20 Feb 2003 09:54:21 -0000 Received: from percy.roke.co.uk (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1KT5SBP3; Thu, 20 Feb 2003 09:54:18 -0000 From: "Conroy, Lawrence (SMTP)" To: "Robert H. Walter" , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <001e01c2d837$62e215e0$2da6cb41@netnumber.com> References: <001e01c2d837$62e215e0$2da6cb41@netnumber.com> Date: Thu, 20 Feb 2003 09:54:14 +0000 Subject: Re: [Enum] Feedback on ENUM Service Registration for MMS Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 11:53 am -0500 19/2/03, Robert H. Walter wrote: >Rudolf, Lawrence and Richard, > >Please consider modifying section 5.4 MMS Service Registration to >include the following subtypes and URI schemes as prescribed by 3GPP TS >23.140 V6.0.0 (2002-12) Multimedia Messaging Service (MMS): > >Subtypes: "smtp", "http" >URI Schemes: "mms" > >Valid NAPTR service field examples for MMS would include: > >"E2U+mms" - Indicates MMS service availability with NO advertised > protocol support. >"E2U+mms:smtp" - Indicates MMS service availability with advertised SMTP > protocol support. >"E2U+mms:http" - Indicates MMS service availability with advertised HTTP > protocol support. > >Regards, > >Bob Walter Hi Robert, folks, Thank you for your feedback. We did consider it. However, as the document to which you refer is a Stage 2 document, it states nothing on protocol issues - you can't inter-operate with a functional spec (other than using the WAP mapping specified in the appendix). Secondly, in the MSG draft, the enumservice indicates that the recipient is capable of receiving multimedia messages, and that the identifier used to address them is in the URI. Note that it does NOT matter how the recipient connects to their service MMSCS, merely the identity they use. All MMS systems currently available (to me, at least) have a phone number as recipient identifier and so our 'mms:tel' is valid. I can use it (and I do, when I can afford the prices :). If a user has instead an email address as their identifier, then what we're talking about is just email - I don't care if they pick up their mail using a webmail system, or by a email/wap/MMS gateway, or even by their Secretary printing out the mail and reading it over the phone to them. It's just email, using the identifier held in the (mailto:) URI. Thus, there is no difference (to the sender of a message) how the recipient receives it; only their identifier is important, and the service provided. Thus for now I don't believe that the extended architecture described in the MMS functional specification document is stable enough (or implemented), so for this registration we have limited ourselves to the service within the overall MMS architecture that exists. That uses phone numbers as the recipient identifier, hence mms:tel. Maybe in the future... all the best, L -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 07:47:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10031 for ; Thu, 20 Feb 2003 07:47:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KCs4h09480 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 07:54:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCrqp09472; Thu, 20 Feb 2003 07:53:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCjVp08993 for ; Thu, 20 Feb 2003 07:45:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09532; Thu, 20 Feb 2003 07:38:27 -0500 (EST) Message-Id: <200302201238.HAA09532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Feb 2003 07:38:27 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-h323-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --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 Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-ietf-enum-h323-00.txt Pages : 4 Date : 2003-2-19 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-h323-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-h323-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19144014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-h323-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-h323-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19144014.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 09:20:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15402 for ; Thu, 20 Feb 2003 09:20:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KEQgY16075 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 09:26:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEQZp16065; Thu, 20 Feb 2003 09:26:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEPPp15994 for ; Thu, 20 Feb 2003 09:25:25 -0500 Received: from smtp6.mindspring.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15306 for ; Thu, 20 Feb 2003 09:18:17 -0500 (EST) Received: from dialup-64.152.234.77.dial1.dallas1.level3.net ([64.152.234.77] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 18lraE-0007z1-00; Thu, 20 Feb 2003 09:21:55 -0500 Message-ID: <3E5500CA.6FD4A47@ix.netcom.com> Date: Thu, 20 Feb 2003 08:22:34 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: rfc-editor@rfc-editor.org, enum@ietf.org, mark.foster@neustar.biz, tom.mcgarry@neustar.biz, james.yu@neustar.biz, Jeff Neuman Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <06CF906FE3998C4E944213062009F1620E9DAF@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Staatny and all, Stastny Richard wrote: > Jeff, > I do not read this. I think you mean you "Did not read this"? If so, do so. > > So what is your problem with this informational document? It is a one organization "Show", namely Nuestar as that one organization. > > I there anything wrong in it? Yes. Read it carefully and completely... > > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 7:13 AM > > To: rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > Global Switched Telephone Network (GSTN): An Overview > > > > > > RFC Editor and all, > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > Has Nuestar taken over a percentage of the IETF recently? > > > > rfc-editor@rfc-editor.org wrote: > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3482 > > > > > > Title: Number Portability in the Global Switched > > > Telephone Network (GSTN): An Overview > > > Author(s): M. Foster, T. McGarry, J. Yu > > > Status: Informational > > > Date: February 2003 > > > Mailbox: mark.foster@neustar.biz, > > tom.mcgarry@neustar.biz, > > > james.yu@neustar.biz > > > Pages: 30 > > > Characters: 78552 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > This document provides an overview of E.164 telephone number > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > NP is a regulatory imperative seeking to liberalize local telephony > > > service competition, by enabling end-users to retain > > telephone numbers > > > while changing service providers. NP changes the > > fundamental nature > > > of a dialed E.164 number from a hierarchical physical > > routing address > > > to a virtual address, thereby requiring the transparent > > translation of > > > the later to the former. In addition, there are various regulatory > > > constraints that establish relevant parameters for NP > > implementation, > > > most of which are not network technology specific. > > Consequently, the > > > implementation of NP behavior consistent with applicable regulatory > > > constraints, as well as the need for interoperation with > > the existing > > > GSTN NP implementations, are relevant topics for numerous > > areas of IP > > > telephony works-in-progress with the IETF. > > > > > > This document is a product of the Telephone Number Mapping Working > > > Group of the IETF. > > > > > > This memo provides information for the Internet community. It does > > > not specify an Internet standard of any kind. Distribution of this > > > memo is unlimited > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > Requests to be added to or deleted from the IETF distribution list > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or > > > deleted from the RFC-DIST distribution list should be sent to > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > by sending > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > help: ways_to_get_rfcs. For example: > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > Subject: getting rfcs > > > > > > help: ways_to_get_rfcs > > > > > > Requests for special distribution should be addressed to either the > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > > for unlimited distribution.echo Submissions for Requests > > for Comments > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > consult RFC 2223, > > > Instructions to RFC Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > USC/Information Sciences Institute > > > > > > ... > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > implementation to automatically retrieve the ASCII version of the > > > RFCs. > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. E-Mail > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 09:35:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15800 for ; Thu, 20 Feb 2003 09:35:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KEg6C17490 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 09:42:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEg6p17485; Thu, 20 Feb 2003 09:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEexp17429 for ; Thu, 20 Feb 2003 09:40:59 -0500 Received: from rainier.illuminet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15765 for ; Thu, 20 Feb 2003 09:33:51 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [10.55.13.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA27062; Thu, 20 Feb 2003 06:37:39 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id <192QZKLX>; Thu, 20 Feb 2003 06:37:39 -0800 Message-ID: <90B62898D7B43B448D1A7297980A8C5F6CE5B1@opwinex01.corp.illuminet.com> From: Kevin McCandless To: Jeff Williams Cc: enum@ietf.org Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 06:37:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Jeff: This is a contribution to educate us on Number Portability. We should be glad that a company like Neustar understands this complex service. What it has to do with ENUM is still anyone's guess. K... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, February 20, 2003 3:16 AM > To: Jeff Williams; rfc-editor@rfc-editor.org > Cc: enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; > james.yu@neustar.biz; Jeff Neuman > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > Switched Telephone Network (GSTN): An Overview > > > Jeff, > I do not read this. > So what is your problem with this informational document? > I there anything wrong in it? > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 7:13 AM > > To: rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > Global Switched Telephone Network (GSTN): An Overview > > > > > > RFC Editor and all, > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > Has Nuestar taken over a percentage of the IETF recently? > > > > rfc-editor@rfc-editor.org wrote: > > > > > A new Request for Comments is now available in online RFC > libraries. > > > > > > RFC 3482 > > > > > > Title: Number Portability in the Global Switched > > > Telephone Network (GSTN): An Overview > > > Author(s): M. Foster, T. McGarry, J. Yu > > > Status: Informational > > > Date: February 2003 > > > Mailbox: mark.foster@neustar.biz, > > tom.mcgarry@neustar.biz, > > > james.yu@neustar.biz > > > Pages: 30 > > > Characters: 78552 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > This document provides an overview of E.164 telephone number > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > NP is a regulatory imperative seeking to liberalize local > telephony > > > service competition, by enabling end-users to retain > > telephone numbers > > > while changing service providers. NP changes the > > fundamental nature > > > of a dialed E.164 number from a hierarchical physical > > routing address > > > to a virtual address, thereby requiring the transparent > > translation of > > > the later to the former. In addition, there are various > regulatory > > > constraints that establish relevant parameters for NP > > implementation, > > > most of which are not network technology specific. > > Consequently, the > > > implementation of NP behavior consistent with applicable > regulatory > > > constraints, as well as the need for interoperation with > > the existing > > > GSTN NP implementations, are relevant topics for numerous > > areas of IP > > > telephony works-in-progress with the IETF. > > > > > > This document is a product of the Telephone Number > Mapping Working > > > Group of the IETF. > > > > > > This memo provides information for the Internet > community. It does > > > not specify an Internet standard of any kind. > Distribution of this > > > memo is unlimited > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > Requests to be added to or deleted from the IETF > distribution list > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or > > > deleted from the RFC-DIST distribution list should be sent to > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > by sending > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > help: ways_to_get_rfcs. For example: > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > Subject: getting rfcs > > > > > > help: ways_to_get_rfcs > > > > > > Requests for special distribution should be addressed to > either the > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > Unless specifically noted otherwise on the RFC itself, > all RFCs are > > > for unlimited distribution.echo Submissions for Requests > > for Comments > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > consult RFC 2223, > > > Instructions to RFC Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > USC/Information Sciences Institute > > > > > > ... > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > implementation to automatically retrieve the ASCII version of the > > > RFCs. > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. E-Mail > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 09:54:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16347 for ; Thu, 20 Feb 2003 09:54:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KF1DR18284 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 10:01:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KF1Cp18279; Thu, 20 Feb 2003 10:01:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KF0ep18227 for ; Thu, 20 Feb 2003 10:00:40 -0500 Received: from bscc-gateway.bscc.bls.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16282 for ; Thu, 20 Feb 2003 09:53:28 -0500 (EST) Received: from sbsccexig01.BSCC.BLS.COM (sbsccexig01.bscc.bls.com [30.3.4.130]) by bscc-gateway.bscc.bls.com (8.9.3/8.9.3) with ESMTP id JAA08713; Thu, 20 Feb 2003 09:57:16 -0500 (EST) Received: by sbsccexig01.BSCC.BLS.COM with Internet Mail Service (5.5.2657.9) id ; Thu, 20 Feb 2003 09:53:33 -0500 Message-ID: <9FE11C074413764C898BC7B6C926422B0A60505B@s30342g004002> From: "Enzmann, Mark" To: Jeff Williams Cc: enum@ietf.org Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 09:57:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D8F0.59EE5F20" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D8F0.59EE5F20 Content-Type: text/plain; charset="iso-8859-1" I'm still waiting for substantive criticism on the content of the document versus an attack on the authors. I thank the authors for taking the time. -----Original Message----- From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] Sent: Thursday, February 20, 2003 11:23 AM To: Stastny Richard Cc: rfc-editor@rfc-editor.org; enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Staatny and all, Stastny Richard wrote: > Jeff, > I do not read this. I think you mean you "Did not read this"? If so, do so. > > So what is your problem with this informational document? It is a one organization "Show", namely Nuestar as that one organization. > > I there anything wrong in it? Yes. Read it carefully and completely... > > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 7:13 AM > > To: rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > Global Switched Telephone Network (GSTN): An Overview > > > > > > RFC Editor and all, > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > Has Nuestar taken over a percentage of the IETF recently? > > > > rfc-editor@rfc-editor.org wrote: > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3482 > > > > > > Title: Number Portability in the Global Switched > > > Telephone Network (GSTN): An Overview > > > Author(s): M. Foster, T. McGarry, J. Yu > > > Status: Informational > > > Date: February 2003 > > > Mailbox: mark.foster@neustar.biz, > > tom.mcgarry@neustar.biz, > > > james.yu@neustar.biz > > > Pages: 30 > > > Characters: 78552 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > This document provides an overview of E.164 telephone number > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > NP is a regulatory imperative seeking to liberalize local telephony > > > service competition, by enabling end-users to retain > > telephone numbers > > > while changing service providers. NP changes the > > fundamental nature > > > of a dialed E.164 number from a hierarchical physical > > routing address > > > to a virtual address, thereby requiring the transparent > > translation of > > > the later to the former. In addition, there are various regulatory > > > constraints that establish relevant parameters for NP > > implementation, > > > most of which are not network technology specific. > > Consequently, the > > > implementation of NP behavior consistent with applicable regulatory > > > constraints, as well as the need for interoperation with > > the existing > > > GSTN NP implementations, are relevant topics for numerous > > areas of IP > > > telephony works-in-progress with the IETF. > > > > > > This document is a product of the Telephone Number Mapping Working > > > Group of the IETF. > > > > > > This memo provides information for the Internet community. It does > > > not specify an Internet standard of any kind. Distribution of this > > > memo is unlimited > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > Requests to be added to or deleted from the IETF distribution list > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or > > > deleted from the RFC-DIST distribution list should be sent to > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > by sending > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > help: ways_to_get_rfcs. For example: > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > Subject: getting rfcs > > > > > > help: ways_to_get_rfcs > > > > > > Requests for special distribution should be addressed to either the > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > Unless specifically noted otherwise on the RFC itself, all RFCs are > > > for unlimited distribution.echo Submissions for Requests > > for Comments > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > consult RFC 2223, > > > Instructions to RFC Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > USC/Information Sciences Institute > > > > > > ... > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > implementation to automatically retrieve the ASCII version of the > > > RFCs. > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. E-Mail > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C2D8F0.59EE5F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] RFC 3482 on Number Portability in the Global Switched = Telephone Network (GSTN): An Overview

I'm still waiting for substantive criticism on the = content of the document versus an attack on the authors.  I thank = the authors for taking the time.

-----Original Message-----
From: Jeff Williams [mailto:jwkckid1@ix.netcom.com= ]
Sent: Thursday, February 20, 2003 11:23 AM
To: Stastny Richard
Cc: rfc-editor@rfc-editor.org; enum@ietf.org; = mark.foster@neustar.biz;
tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff = Neuman
Subject: Re: [Enum] RFC 3482 on Number Portability = in the Global
Switched Telephone Network (GSTN): An = Overview


Staatny and all,

Stastny Richard wrote:

> Jeff,
> I do not read this.

  I think you mean you "Did not read = this"?
If so, do so.

>
> So what is your problem with this informational = document?

  It is a one organization "Show", = namely Nuestar as that
one organization.

>
> I there anything wrong in it?

Yes.  Read it carefully and completely...

>
> Richard
>
> > -----Original Message-----
> > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com= ]
> > Sent: Thursday, February 20, 2003 7:13 = AM
> > To: rfc-editor@rfc-editor.org
> > Cc: enum@ietf.org; = mark.foster@neustar.biz;
> > tom.mcgarry@neustar.biz; = james.yu@neustar.biz; Jeff Neuman
> > Subject: Re: [Enum] RFC 3482 on Number = Portability in the
> > Global Switched Telephone Network (GSTN): = An Overview
> >
> >
> > RFC Editor and all,
> >
> >   Looks an awful lot like a = Nuestar/IEGF document/RFC to me.
> > Has Nuestar taken over a percentage of the = IETF recently?
> >
> > rfc-editor@rfc-editor.org wrote:
> >
> > > A new Request for Comments is now = available in online RFC libraries.
> > >
> > = >         RFC 3482
> > >
> > = >         = Title:      Number Portability in the Global = Switched
> > = >           &n= bsp;         Telephone Network = (GSTN): An Overview
> > = >         Author(s):  = M. Foster, T. McGarry, J. Yu
> > = >         = Status:     Informational
> > = >         = Date:       February 2003
> > = >         = Mailbox:    mark.foster@neustar.biz,
> > tom.mcgarry@neustar.biz,
> > = >           &n= bsp;         = james.yu@neustar.biz
> > = >         = Pages:      30
> > = >         Characters: = 78552
> > = >         = Updates/Obsoletes/SeeAlso:    None
> > >
> > = >         I-D = Tag:    draft-ietf-enum-e164-gstn-np-05.txt
> > >
> > = >         = URL:       ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt
> > >
> > > This document provides an overview of = E.164 telephone number
> > > portability (NP) in the Global = Switched Telephone Network (GSTN).
> > >
> > > NP is a regulatory imperative seeking = to liberalize local telephony
> > > service competition, by enabling = end-users to retain
> > telephone numbers
> > > while changing service = providers.  NP changes the
> > fundamental nature
> > > of a dialed E.164 number from a = hierarchical physical
> > routing address
> > > to a virtual address, thereby = requiring the transparent
> > translation of
> > > the later to the former.  In = addition, there are various regulatory
> > > constraints that establish relevant = parameters for NP
> > implementation,
> > > most of which are not network = technology specific.
> > Consequently, the
> > > implementation of NP behavior = consistent with applicable regulatory
> > > constraints, as well as the need for = interoperation with
> > the existing
> > > GSTN NP implementations, are relevant = topics for numerous
> > areas of IP
> > > telephony works-in-progress with the = IETF.
> > >
> > > This document is a product of the = Telephone Number Mapping Working
> > > Group of the IETF.
> > >
> > > This memo provides information for = the Internet community.  It does
> > > not specify an Internet standard of = any kind.  Distribution of this
> > > memo is unlimited
> > >
> > > This announcement is sent to the IETF = list and the RFC-DIST list.
> > > Requests to be added to or deleted = from the IETF distribution list
> > > should be sent to = IETF-REQUEST@IETF.ORG.  Requests to be
> > added to or
> > > deleted from the RFC-DIST = distribution list should be sent to
> > > = RFC-DIST-REQUEST@RFC-EDITOR.ORG.
> > >
> > > Details on obtaining RFCs via FTP or = EMAIL may be obtained
> > by sending
> > > an EMAIL message to = rfc-info@RFC-EDITOR.ORG with the message body
> > > help: ways_to_get_rfcs.  For = example:
> > >
> > = >         To: = rfc-info@RFC-EDITOR.ORG
> > = >         Subject: getting = rfcs
> > >
> > = >         help: = ways_to_get_rfcs
> > >
> > > Requests for special distribution = should be addressed to either the
> > > author of the RFC in question, or to = RFC-Manager@RFC-EDITOR.ORG.
> > > Unless specifically noted otherwise = on the RFC itself, all RFCs are
> > > for unlimited distribution.echo = Submissions for Requests
> > for Comments
> > > should be sent to = RFC-EDITOR@RFC-EDITOR.ORG.  Please
> > consult RFC 2223,
> > > Instructions to RFC Authors, for = further information.
> > >
> > > Joyce K. Reynolds and Sandy = Ginoza
> > > USC/Information Sciences = Institute
> > >
> > > ...
> > >
> > > Below is the data which will enable a = MIME compliant Mail Reader
> > > implementation to automatically = retrieve the ASCII version of the
> > > RFCs.
> >
> > Regards,
> >
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 129k = members/stakeholders
> > strong!)
> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > CEO/DIR. Internet Network Eng. SR. Eng. = Network data security
> > Information Network Eng. Group. INEG. INC. = E-Mail
> > jwkckid1@ix.netcom.com Contact Number: = 214-244-4827 or 214-244-3801
> >
> >
> > = _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum=
> >

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 129k = members/stakeholders strong!)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CEO/DIR. Internet Network Eng. SR. Eng. Network data = security
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 214-244-3801


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

------_=_NextPart_001_01C2D8F0.59EE5F20-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 09:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16427 for ; Thu, 20 Feb 2003 09:56:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KF36018382 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 10:03:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KF36p18377; Thu, 20 Feb 2003 10:03:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KF2Lp18349 for ; Thu, 20 Feb 2003 10:02:21 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16390 for ; Thu, 20 Feb 2003 09:55:13 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1KEPKBn001089 for ; Thu, 20 Feb 2003 08:59:03 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E02A4FF63; Thu, 20 Feb 2003 09:59:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 09:58:56 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F905C9DE31@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Thread-Index: AcLY7wWi/ixyncFYRNSW8LnCOikv9QAANAXw From: "Pfautz, Penn L, ALABS" To: "Kevin McCandless" , "Jeff Williams" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KF2Lp18350 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Can't resist: Actually, what LNP has to do with ENUM is this: By unchaining numbers from the service providers to which the codes were assigned, it pushes you to have a line level (10-d in the NANP) Tier 1 registry. This seems obvious now, but in some of the early work group documentation there was discussion that ENUM delegation might follow telephone number (office code) delegation to telcos. James Yu and I touched on this in an I-D a couple years back. Penn Pfautz AT&T -----Original Message----- From: Kevin McCandless [mailto:KMcCandless@verisign.com] Sent: Thursday, February 20, 2003 9:38 AM To: Jeff Williams Cc: enum@ietf.org Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Jeff: This is a contribution to educate us on Number Portability. We should be glad that a company like Neustar understands this complex service. What it has to do with ENUM is still anyone's guess. K... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, February 20, 2003 3:16 AM > To: Jeff Williams; rfc-editor@rfc-editor.org > Cc: enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; > james.yu@neustar.biz; Jeff Neuman > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > Switched Telephone Network (GSTN): An Overview > > > Jeff, > I do not read this. > So what is your problem with this informational document? > I there anything wrong in it? > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 7:13 AM > > To: rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > Global Switched Telephone Network (GSTN): An Overview > > > > > > RFC Editor and all, > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > Has Nuestar taken over a percentage of the IETF recently? > > > > rfc-editor@rfc-editor.org wrote: > > > > > A new Request for Comments is now available in online RFC > libraries. > > > > > > RFC 3482 > > > > > > Title: Number Portability in the Global Switched > > > Telephone Network (GSTN): An Overview > > > Author(s): M. Foster, T. McGarry, J. Yu > > > Status: Informational > > > Date: February 2003 > > > Mailbox: mark.foster@neustar.biz, > > tom.mcgarry@neustar.biz, > > > james.yu@neustar.biz > > > Pages: 30 > > > Characters: 78552 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > This document provides an overview of E.164 telephone number > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > NP is a regulatory imperative seeking to liberalize local > telephony > > > service competition, by enabling end-users to retain > > telephone numbers > > > while changing service providers. NP changes the > > fundamental nature > > > of a dialed E.164 number from a hierarchical physical > > routing address > > > to a virtual address, thereby requiring the transparent > > translation of > > > the later to the former. In addition, there are various > regulatory > > > constraints that establish relevant parameters for NP > > implementation, > > > most of which are not network technology specific. > > Consequently, the > > > implementation of NP behavior consistent with applicable > regulatory > > > constraints, as well as the need for interoperation with > > the existing > > > GSTN NP implementations, are relevant topics for numerous > > areas of IP > > > telephony works-in-progress with the IETF. > > > > > > This document is a product of the Telephone Number > Mapping Working > > > Group of the IETF. > > > > > > This memo provides information for the Internet > community. It does > > > not specify an Internet standard of any kind. > Distribution of this > > > memo is unlimited > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > Requests to be added to or deleted from the IETF > distribution list > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or > > > deleted from the RFC-DIST distribution list should be sent to > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > by sending > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > help: ways_to_get_rfcs. For example: > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > Subject: getting rfcs > > > > > > help: ways_to_get_rfcs > > > > > > Requests for special distribution should be addressed to > either the > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > Unless specifically noted otherwise on the RFC itself, > all RFCs are > > > for unlimited distribution.echo Submissions for Requests > > for Comments > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > consult RFC 2223, > > > Instructions to RFC Authors, for further information. > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > USC/Information Sciences Institute > > > > > > ... > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > implementation to automatically retrieve the ASCII version of the > > > RFCs. > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. E-Mail > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 10:40:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18367 for ; Thu, 20 Feb 2003 10:40:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFkt922286 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 10:46:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFkqp22280; Thu, 20 Feb 2003 10:46:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFjrp22180 for ; Thu, 20 Feb 2003 10:45:53 -0500 Received: from mclean.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18276 for ; Thu, 20 Feb 2003 10:38:44 -0500 (EST) Received: from dialup-64.152.234.77.dial1.dallas1.level3.net ([64.152.234.77] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18lsqF-0003ax-00; Thu, 20 Feb 2003 10:42:32 -0500 Message-ID: <3E5513AF.B49E4A8A@ix.netcom.com> Date: Thu, 20 Feb 2003 09:43:12 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Kevin McCandless CC: enum@ietf.org Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <90B62898D7B43B448D1A7297980A8C5F6CE5B1@opwinex01.corp.illuminet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin and all, Number portability is not a new technology by any means. It has been used in the Military for at least two decades that I am aware of and have some experience with. Nuestar is not the only company/organization that has broad experience in this arena either. But your right that what this has to do with ENUM is anyone's guess, just now... However I can see some interesting correlation's here... Hence my concern... So I prefer to stay ahead of the curve, so to speak... >;) Kevin McCandless wrote: > Jeff: > > This is a contribution to educate us on Number Portability. We should be > glad that a company like Neustar understands this complex service. What it > has to do with ENUM is still anyone's guess. > > K... > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, February 20, 2003 3:16 AM > > To: Jeff Williams; rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; > > james.yu@neustar.biz; Jeff Neuman > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > Switched Telephone Network (GSTN): An Overview > > > > > > Jeff, > > I do not read this. > > So what is your problem with this informational document? > > I there anything wrong in it? > > Richard > > > > > -----Original Message----- > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > Sent: Thursday, February 20, 2003 7:13 AM > > > To: rfc-editor@rfc-editor.org > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > > Global Switched Telephone Network (GSTN): An Overview > > > > > > > > > RFC Editor and all, > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > > Has Nuestar taken over a percentage of the IETF recently? > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > A new Request for Comments is now available in online RFC > > libraries. > > > > > > > > RFC 3482 > > > > > > > > Title: Number Portability in the Global Switched > > > > Telephone Network (GSTN): An Overview > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > Status: Informational > > > > Date: February 2003 > > > > Mailbox: mark.foster@neustar.biz, > > > tom.mcgarry@neustar.biz, > > > > james.yu@neustar.biz > > > > Pages: 30 > > > > Characters: 78552 > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > This document provides an overview of E.164 telephone number > > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > telephony > > > > service competition, by enabling end-users to retain > > > telephone numbers > > > > while changing service providers. NP changes the > > > fundamental nature > > > > of a dialed E.164 number from a hierarchical physical > > > routing address > > > > to a virtual address, thereby requiring the transparent > > > translation of > > > > the later to the former. In addition, there are various > > regulatory > > > > constraints that establish relevant parameters for NP > > > implementation, > > > > most of which are not network technology specific. > > > Consequently, the > > > > implementation of NP behavior consistent with applicable > > regulatory > > > > constraints, as well as the need for interoperation with > > > the existing > > > > GSTN NP implementations, are relevant topics for numerous > > > areas of IP > > > > telephony works-in-progress with the IETF. > > > > > > > > This document is a product of the Telephone Number > > Mapping Working > > > > Group of the IETF. > > > > > > > > This memo provides information for the Internet > > community. It does > > > > not specify an Internet standard of any kind. > > Distribution of this > > > > memo is unlimited > > > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > > Requests to be added to or deleted from the IETF > > distribution list > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > added to or > > > > deleted from the RFC-DIST distribution list should be sent to > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > by sending > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > > help: ways_to_get_rfcs. For example: > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > Subject: getting rfcs > > > > > > > > help: ways_to_get_rfcs > > > > > > > > Requests for special distribution should be addressed to > > either the > > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > > Unless specifically noted otherwise on the RFC itself, > > all RFCs are > > > > for unlimited distribution.echo Submissions for Requests > > > for Comments > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > consult RFC 2223, > > > > Instructions to RFC Authors, for further information. > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > USC/Information Sciences Institute > > > > > > > > ... > > > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > > implementation to automatically retrieve the ASCII version of the > > > > RFCs. > > > > > > Regards, > > > > > > -- > > > Jeffrey A. Williams > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > strong!) > > > ================================================================ > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > Information Network Eng. Group. INEG. INC. E-Mail > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 10:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18620 for ; Thu, 20 Feb 2003 10:48:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFt6J22719 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 10:55:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFt6p22714; Thu, 20 Feb 2003 10:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFs8p22653 for ; Thu, 20 Feb 2003 10:54:08 -0500 Received: from hall.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18559 for ; Thu, 20 Feb 2003 10:46:58 -0500 (EST) Received: from dialup-64.152.234.77.dial1.dallas1.level3.net ([64.152.234.77] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18lsyC-0001je-00; Thu, 20 Feb 2003 10:50:44 -0500 Message-ID: <3E55159B.345ED26@ix.netcom.com> Date: Thu, 20 Feb 2003 09:51:24 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Pfautz, Penn L, ALABS" CC: Kevin McCandless , enum@ietf.org Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <62DA45D4963FA747BA1B253E266760F905C9DE31@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Penn and all, Thanks Penn for this info/update. And ENUM could easily follow as well as you indicate. Hence again in part my original concerns. I am glad that you caught that in my original response and second follow-up. The other part of my response was addressing that fact that ONLY ONE company was the author of RFC 3482 and as others companies and organizations are working on ENUM apps and implementations such as a RFC is perhaps inconsistent with good standards development practice... Pfautz, Penn L, ALABS wrote: > Can't resist: > > Actually, what LNP has to do with ENUM is this: By unchaining numbers from the service providers to which the codes were assigned, it pushes you to have a line level (10-d in the NANP) Tier 1 registry. This seems obvious now, but in some of the early work group documentation there was discussion that ENUM delegation might follow telephone number (office code) delegation to telcos. James Yu and I touched on this in an I-D a couple years back. > > Penn Pfautz > AT&T > > -----Original Message----- > From: Kevin McCandless [mailto:KMcCandless@verisign.com] > Sent: Thursday, February 20, 2003 9:38 AM > To: Jeff Williams > Cc: enum@ietf.org > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > Switched Telephone Network (GSTN): An Overview > > Jeff: > > This is a contribution to educate us on Number Portability. We should be > glad that a company like Neustar understands this complex service. What it > has to do with ENUM is still anyone's guess. > > K... > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, February 20, 2003 3:16 AM > > To: Jeff Williams; rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; > > james.yu@neustar.biz; Jeff Neuman > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > Switched Telephone Network (GSTN): An Overview > > > > > > Jeff, > > I do not read this. > > So what is your problem with this informational document? > > I there anything wrong in it? > > Richard > > > > > -----Original Message----- > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > Sent: Thursday, February 20, 2003 7:13 AM > > > To: rfc-editor@rfc-editor.org > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > > Global Switched Telephone Network (GSTN): An Overview > > > > > > > > > RFC Editor and all, > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > > Has Nuestar taken over a percentage of the IETF recently? > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > A new Request for Comments is now available in online RFC > > libraries. > > > > > > > > RFC 3482 > > > > > > > > Title: Number Portability in the Global Switched > > > > Telephone Network (GSTN): An Overview > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > Status: Informational > > > > Date: February 2003 > > > > Mailbox: mark.foster@neustar.biz, > > > tom.mcgarry@neustar.biz, > > > > james.yu@neustar.biz > > > > Pages: 30 > > > > Characters: 78552 > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > This document provides an overview of E.164 telephone number > > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > telephony > > > > service competition, by enabling end-users to retain > > > telephone numbers > > > > while changing service providers. NP changes the > > > fundamental nature > > > > of a dialed E.164 number from a hierarchical physical > > > routing address > > > > to a virtual address, thereby requiring the transparent > > > translation of > > > > the later to the former. In addition, there are various > > regulatory > > > > constraints that establish relevant parameters for NP > > > implementation, > > > > most of which are not network technology specific. > > > Consequently, the > > > > implementation of NP behavior consistent with applicable > > regulatory > > > > constraints, as well as the need for interoperation with > > > the existing > > > > GSTN NP implementations, are relevant topics for numerous > > > areas of IP > > > > telephony works-in-progress with the IETF. > > > > > > > > This document is a product of the Telephone Number > > Mapping Working > > > > Group of the IETF. > > > > > > > > This memo provides information for the Internet > > community. It does > > > > not specify an Internet standard of any kind. > > Distribution of this > > > > memo is unlimited > > > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > > Requests to be added to or deleted from the IETF > > distribution list > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > added to or > > > > deleted from the RFC-DIST distribution list should be sent to > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > by sending > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > > help: ways_to_get_rfcs. For example: > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > Subject: getting rfcs > > > > > > > > help: ways_to_get_rfcs > > > > > > > > Requests for special distribution should be addressed to > > either the > > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > > Unless specifically noted otherwise on the RFC itself, > > all RFCs are > > > > for unlimited distribution.echo Submissions for Requests > > > for Comments > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > consult RFC 2223, > > > > Instructions to RFC Authors, for further information. > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > USC/Information Sciences Institute > > > > > > > > ... > > > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > > implementation to automatically retrieve the ASCII version of the > > > > RFCs. > > > > > > Regards, > > > > > > -- > > > Jeffrey A. Williams > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > strong!) > > > ================================================================ > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > Information Network Eng. Group. INEG. INC. E-Mail > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 11:27:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20097 for ; Thu, 20 Feb 2003 11:27:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGY8m25745 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 11:34:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGXfp25684; Thu, 20 Feb 2003 11:33:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGVfp25561 for ; Thu, 20 Feb 2003 11:31:41 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20020 for ; Thu, 20 Feb 2003 11:24:30 -0500 (EST) Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 17:32:01 +0100 MIME-Version: 1.0 Message-ID: <06CF906FE3998C4E944213062009F1620E9DB5@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Thread-Index: AcLY+Obn09egNm1zQf+AgGRR7b2OxAAA52CQ From: "Stastny Richard" To: "Jeff Williams" , "Kevin McCandless" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KGVfp25562 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jeff, Just one additional question before I reread the document: I am also not reading the company you are always blaming: Nuestar Could it be you are talking about Neustar? Richard > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Thursday, February 20, 2003 6:43 PM > To: Kevin McCandless > Cc: enum@ietf.org > Subject: Re: [Enum] RFC 3482 on Number Portability in the > Global Switched Telephone Network (GSTN): An Overview > > > Kevin and all, > > Number portability is not a new technology by any means. > It has been used in the Military for at least two decades > that I am aware of and have some experience with. Nuestar is > not the only company/organization that has broad experience > in this arena either. > > But your right that what this has to do with ENUM is > anyone's guess, just now... However I can see some > interesting correlation's here... Hence my concern... So I > prefer to stay ahead of the curve, so to speak... >;) > > Kevin McCandless wrote: > > > Jeff: > > > > This is a contribution to educate us on Number Portability. > We should > > be glad that a company like Neustar understands this > complex service. > > What it has to do with ENUM is still anyone's guess. > > > > K... > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, February 20, 2003 3:16 AM > > > To: Jeff Williams; rfc-editor@rfc-editor.org > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > tom.mcgarry@neustar.biz; > > > james.yu@neustar.biz; Jeff Neuman > > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > Jeff, > > > I do not read this. > > > So what is your problem with this informational document? > > > I there anything wrong in it? > > > Richard > > > > > > > -----Original Message----- > > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > > Sent: Thursday, February 20, 2003 7:13 AM > > > > To: rfc-editor@rfc-editor.org > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > > Subject: Re: [Enum] RFC 3482 on Number Portability in > the Global > > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > RFC Editor and all, > > > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC > to me. Has > > > > Nuestar taken over a percentage of the IETF recently? > > > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > > > A new Request for Comments is now available in online RFC > > > libraries. > > > > > > > > > > RFC 3482 > > > > > > > > > > Title: Number Portability in the Global Switched > > > > > Telephone Network (GSTN): An Overview > > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > > Status: Informational > > > > > Date: February 2003 > > > > > Mailbox: mark.foster@neustar.biz, > > > > tom.mcgarry@neustar.biz, > > > > > james.yu@neustar.biz > > > > > Pages: 30 > > > > > Characters: 78552 > > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > > > URL: > ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > > > This document provides an overview of E.164 telephone number > > > > > portability (NP) in the Global Switched Telephone Network > > > > > (GSTN). > > > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > > telephony > > > > > service competition, by enabling end-users to retain > > > > telephone numbers > > > > > while changing service providers. NP changes the > > > > fundamental nature > > > > > of a dialed E.164 number from a hierarchical physical > > > > routing address > > > > > to a virtual address, thereby requiring the transparent > > > > translation of > > > > > the later to the former. In addition, there are various > > > regulatory > > > > > constraints that establish relevant parameters for NP > > > > implementation, > > > > > most of which are not network technology specific. > > > > Consequently, the > > > > > implementation of NP behavior consistent with applicable > > > regulatory > > > > > constraints, as well as the need for interoperation with > > > > the existing > > > > > GSTN NP implementations, are relevant topics for numerous > > > > areas of IP > > > > > telephony works-in-progress with the IETF. > > > > > > > > > > This document is a product of the Telephone Number > > > Mapping Working > > > > > Group of the IETF. > > > > > > > > > > This memo provides information for the Internet > > > community. It does > > > > > not specify an Internet standard of any kind. > > > Distribution of this > > > > > memo is unlimited > > > > > > > > > > This announcement is sent to the IETF list and the RFC-DIST > > > > > list. Requests to be added to or deleted from the IETF > > > distribution list > > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > > added to or > > > > > deleted from the RFC-DIST distribution list should be sent to > > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > > by sending > > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message > > > > > body > > > > > help: ways_to_get_rfcs. For example: > > > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > > Subject: getting rfcs > > > > > > > > > > help: ways_to_get_rfcs > > > > > > > > > > Requests for special distribution should be addressed to > > > either the > > > > > author of the RFC in question, or to > RFC-Manager@RFC-EDITOR.ORG. > > > > > Unless specifically noted otherwise on the RFC itself, > > > all RFCs are > > > > > for unlimited distribution.echo Submissions for Requests > > > > for Comments > > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > > consult RFC 2223, > > > > > Instructions to RFC Authors, for further information. > > > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > > USC/Information Sciences Institute > > > > > > > > > > ... > > > > > > > > > > Below is the data which will enable a MIME compliant > Mail Reader > > > > > implementation to automatically retrieve the ASCII version of > > > > > the RFCs. > > > > > > > > Regards, > > > > > > > > -- > > > > Jeffrey A. Williams > > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > > strong!) > > > > ================================================================ > > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > > Information Network Eng. Group. INEG. INC. E-Mail > > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or > > > > 214-244-3801 > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > Regards, > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > strong!) > ================================================================ > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > Information Network Eng. Group. INEG. INC. E-Mail > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 11:31:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20233 for ; Thu, 20 Feb 2003 11:31:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGc3426714 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 11:38:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGc3p26709; Thu, 20 Feb 2003 11:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGb4p26023 for ; Thu, 20 Feb 2003 11:37:04 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20179 for ; Thu, 20 Feb 2003 11:29:53 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1KGXZC11413; Thu, 20 Feb 2003 16:33:35 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 11:33:43 -0500 Message-ID: <25A36E32FDC7D511827600306E1C196201168172@CHLAEXCH1> From: "Yu, James" To: "'Jeff Williams'" Cc: enum@ietf.org Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 11:35:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Jeff, I am in CA and just saw the discussions. First, this is an informational RFC, so it is not a "standard" such as the SIP RFC. NeuStar examined the impacts of NP on many of IETF's current activities and the potential areas that might be caused by NP. One area was ENUM (that was why this document was submitted to the enum WG). As indicated by Penn, NeuStar and AT&T jointly investigated the impact of NP on the ENUM provisioning process and showed how the provisioning process would be done if the telephony carriers and the subscribers share the common domain tree (e.g., e164.arpa). The process became complicate when NP is involved because the new telephony carrier's NAPTR RRs must be used when the subscriber (ENUM user or ENUM registrant) changes the telephony carrier. We recommended that "carrier" ENUM (or "infrastructure" ENUM," - the use of ENUM by the telephony carriers) use a different domain tree to avoid involving NP in the ENUM provisioning process. We have identified several other issues such as those related to iptel WG and convergence. Please see the last section that discusses those issues. Hope that the above providess the clarifications. James > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Thursday, February 20, 2003 12:43 PM > To: Kevin McCandless > Cc: enum@ietf.org > Subject: Re: [Enum] RFC 3482 on Number Portability in the Global > Switched Telephone Network (GSTN): An Overview > > > Kevin and all, > > Number portability is not a new technology by any means. > It has been > used in the Military for at least two decades that I am aware of and > have some experience with. Nuestar is not the only > company/organization > that has broad experience in this arena either. > > But your right that what this has to do with ENUM is anyone's > guess, just now... However I can see some interesting correlation's > here... Hence my concern... So I prefer to stay ahead of the > curve, so to speak... >;) > > Kevin McCandless wrote: > > > Jeff: > > > > This is a contribution to educate us on Number Portability. > We should be > > glad that a company like Neustar understands this complex > service. What it > > has to do with ENUM is still anyone's guess. > > > > K... > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, February 20, 2003 3:16 AM > > > To: Jeff Williams; rfc-editor@rfc-editor.org > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > tom.mcgarry@neustar.biz; > > > james.yu@neustar.biz; Jeff Neuman > > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > Jeff, > > > I do not read this. > > > So what is your problem with this informational document? > > > I there anything wrong in it? > > > Richard > > > > > > > -----Original Message----- > > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > > Sent: Thursday, February 20, 2003 7:13 AM > > > > To: rfc-editor@rfc-editor.org > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > > > Global Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > RFC Editor and all, > > > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > > > Has Nuestar taken over a percentage of the IETF recently? > > > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > > > A new Request for Comments is now available in online RFC > > > libraries. > > > > > > > > > > RFC 3482 > > > > > > > > > > Title: Number Portability in the Global Switched > > > > > Telephone Network (GSTN): An Overview > > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > > Status: Informational > > > > > Date: February 2003 > > > > > Mailbox: mark.foster@neustar.biz, > > > > tom.mcgarry@neustar.biz, > > > > > james.yu@neustar.biz > > > > > Pages: 30 > > > > > Characters: 78552 > > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > > > URL: > ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > > > This document provides an overview of E.164 telephone number > > > > > portability (NP) in the Global Switched Telephone > Network (GSTN). > > > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > > telephony > > > > > service competition, by enabling end-users to retain > > > > telephone numbers > > > > > while changing service providers. NP changes the > > > > fundamental nature > > > > > of a dialed E.164 number from a hierarchical physical > > > > routing address > > > > > to a virtual address, thereby requiring the transparent > > > > translation of > > > > > the later to the former. In addition, there are various > > > regulatory > > > > > constraints that establish relevant parameters for NP > > > > implementation, > > > > > most of which are not network technology specific. > > > > Consequently, the > > > > > implementation of NP behavior consistent with applicable > > > regulatory > > > > > constraints, as well as the need for interoperation with > > > > the existing > > > > > GSTN NP implementations, are relevant topics for numerous > > > > areas of IP > > > > > telephony works-in-progress with the IETF. > > > > > > > > > > This document is a product of the Telephone Number > > > Mapping Working > > > > > Group of the IETF. > > > > > > > > > > This memo provides information for the Internet > > > community. It does > > > > > not specify an Internet standard of any kind. > > > Distribution of this > > > > > memo is unlimited > > > > > > > > > > This announcement is sent to the IETF list and the > RFC-DIST list. > > > > > Requests to be added to or deleted from the IETF > > > distribution list > > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > > added to or > > > > > deleted from the RFC-DIST distribution list should be sent to > > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > > by sending > > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the > message body > > > > > help: ways_to_get_rfcs. For example: > > > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > > Subject: getting rfcs > > > > > > > > > > help: ways_to_get_rfcs > > > > > > > > > > Requests for special distribution should be addressed to > > > either the > > > > > author of the RFC in question, or to > RFC-Manager@RFC-EDITOR.ORG. > > > > > Unless specifically noted otherwise on the RFC itself, > > > all RFCs are > > > > > for unlimited distribution.echo Submissions for Requests > > > > for Comments > > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > > consult RFC 2223, > > > > > Instructions to RFC Authors, for further information. > > > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > > USC/Information Sciences Institute > > > > > > > > > > ... > > > > > > > > > > Below is the data which will enable a MIME compliant > Mail Reader > > > > > implementation to automatically retrieve the ASCII > version of the > > > > > RFCs. > > > > > > > > Regards, > > > > > > > > -- > > > > Jeffrey A. Williams > > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > > strong!) > > > > ================================================================ > > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > > Information Network Eng. Group. INEG. INC. E-Mail > > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or > 214-244-3801 > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > Regards, > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) > ================================================================ > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 214-244-4827 or 214-244-3801 > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 11:41:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20597 for ; Thu, 20 Feb 2003 11:41:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGm8327424 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 11:48:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGm7p27419; Thu, 20 Feb 2003 11:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGl2p27338 for ; Thu, 20 Feb 2003 11:47:02 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20528 for ; Thu, 20 Feb 2003 11:39:52 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030220160248.FJGT3860.mailhost.chi1.ameritech.net@repligate> for ; Thu, 20 Feb 2003 10:02:48 -0600 Message-ID: <1b7e01c2d8f9$91e5fba0$8500a8c0@repligate> From: "Jim Fleming" To: References: <90B62898D7B43B448D1A7297980A8C5F6CE5B1@opwinex01.corp.illuminet.com> Date: Thu, 20 Feb 2003 10:03:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 7bit Subject: [Enum] "This is a contribution to educate us..." ? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Kevin McCandless" "This is a contribution to educate us..." ================================ It appears that education, especially in the .US, is very one-sided... ...do you really think enlightened people are fooled any more ? Jim Fleming http://IPv8.isfun.net ----- Original Message ----- From: "Kevin McCandless" To: "Jeff Williams" Cc: Sent: Thursday, February 20, 2003 8:37 AM Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview > Jeff: > > This is a contribution to educate us on Number Portability. We should be > glad that a company like Neustar understands this complex service. What it > has to do with ENUM is still anyone's guess. > > K... > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, February 20, 2003 3:16 AM > > To: Jeff Williams; rfc-editor@rfc-editor.org > > Cc: enum@ietf.org; mark.foster@neustar.biz; tom.mcgarry@neustar.biz; > > james.yu@neustar.biz; Jeff Neuman > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > Switched Telephone Network (GSTN): An Overview > > > > > > Jeff, > > I do not read this. > > So what is your problem with this informational document? > > I there anything wrong in it? > > Richard > > > > > -----Original Message----- > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > Sent: Thursday, February 20, 2003 7:13 AM > > > To: rfc-editor@rfc-editor.org > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > > Global Switched Telephone Network (GSTN): An Overview > > > > > > > > > RFC Editor and all, > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > > Has Nuestar taken over a percentage of the IETF recently? > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > A new Request for Comments is now available in online RFC > > libraries. > > > > > > > > RFC 3482 > > > > > > > > Title: Number Portability in the Global Switched > > > > Telephone Network (GSTN): An Overview > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > Status: Informational > > > > Date: February 2003 > > > > Mailbox: mark.foster@neustar.biz, > > > tom.mcgarry@neustar.biz, > > > > james.yu@neustar.biz > > > > Pages: 30 > > > > Characters: 78552 > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > This document provides an overview of E.164 telephone number > > > > portability (NP) in the Global Switched Telephone Network (GSTN). > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > telephony > > > > service competition, by enabling end-users to retain > > > telephone numbers > > > > while changing service providers. NP changes the > > > fundamental nature > > > > of a dialed E.164 number from a hierarchical physical > > > routing address > > > > to a virtual address, thereby requiring the transparent > > > translation of > > > > the later to the former. In addition, there are various > > regulatory > > > > constraints that establish relevant parameters for NP > > > implementation, > > > > most of which are not network technology specific. > > > Consequently, the > > > > implementation of NP behavior consistent with applicable > > regulatory > > > > constraints, as well as the need for interoperation with > > > the existing > > > > GSTN NP implementations, are relevant topics for numerous > > > areas of IP > > > > telephony works-in-progress with the IETF. > > > > > > > > This document is a product of the Telephone Number > > Mapping Working > > > > Group of the IETF. > > > > > > > > This memo provides information for the Internet > > community. It does > > > > not specify an Internet standard of any kind. > > Distribution of this > > > > memo is unlimited > > > > > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > > > Requests to be added to or deleted from the IETF > > distribution list > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > added to or > > > > deleted from the RFC-DIST distribution list should be sent to > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > by sending > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > > help: ways_to_get_rfcs. For example: > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > Subject: getting rfcs > > > > > > > > help: ways_to_get_rfcs > > > > > > > > Requests for special distribution should be addressed to > > either the > > > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > > > > Unless specifically noted otherwise on the RFC itself, > > all RFCs are > > > > for unlimited distribution.echo Submissions for Requests > > > for Comments > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > consult RFC 2223, > > > > Instructions to RFC Authors, for further information. > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > USC/Information Sciences Institute > > > > > > > > ... > > > > > > > > Below is the data which will enable a MIME compliant Mail Reader > > > > implementation to automatically retrieve the ASCII version of the > > > > RFCs. > > > > > > Regards, > > > > > > -- > > > Jeffrey A. Williams > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > strong!) > > > ================================================================ > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > Information Network Eng. Group. INEG. INC. E-Mail > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 11:51:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21035 for ; Thu, 20 Feb 2003 11:51:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGvlH28342 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 11:57:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGvlp28336; Thu, 20 Feb 2003 11:57:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGuGp28217 for ; Thu, 20 Feb 2003 11:56:16 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20954 for ; Thu, 20 Feb 2003 11:49:05 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1J2JRMGG>; Thu, 20 Feb 2003 16:52:55 -0000 Received: from percy.roke.co.uk (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1KT5SCPY; Thu, 20 Feb 2003 16:52:49 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: james.yu@neustar.biz Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: <3E389566.2E3E7F08@ix.netcom.com> <76347.1043891647@shell.nominum.com> Date: Thu, 20 Feb 2003 16:52:47 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Trollfood Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 7:35 pm -0800 29/1/03, Randy Bush wrote: > > To: Jeff Williams > >helloooo! feeding trolls, are we? bored? not enough email because spam >filters are working too well? > >randy ...and At 11:37 pm -0800 29/1/03, David Conrad wrote: >Randy is right. One shouldn't feed the trolls. I knew better, but >still allowed myself to be slimed. > >Apologies, folks. > >For those that aren't aware of what "Jeffrey A. Williams" is, see >http://www.gtld-mou.org/gtld-discuss/mail-archive/08030.html > >Sigh. > -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 12:59:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23095 for ; Thu, 20 Feb 2003 12:59:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KI5kO01397 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 13:05:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI5gp01392; Thu, 20 Feb 2003 13:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI4Ep01348 for ; Thu, 20 Feb 2003 13:04:14 -0500 Received: from smtp10.atl.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23064 for ; Thu, 20 Feb 2003 12:57:01 -0500 (EST) Received: from dialup-64.152.233.18.dial1.dallas1.level3.net ([64.152.233.18] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 18lv02-0008QR-00; Thu, 20 Feb 2003 13:00:47 -0500 Message-ID: <3E553416.D01BAEAA@ix.netcom.com> Date: Thu, 20 Feb 2003 12:01:27 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: Kevin McCandless , enum@ietf.org Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <06CF906FE3998C4E944213062009F1620E9DB5@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Srastny and all, I am sorry if it appears that I am singling out Nuestar. I didn't believe that my comments indicated such. ANY RFC who's authors are exclusively from one company seems less than adequate for the IETF standards practice would or should allow for. Yet I am personally a strong proponent for more commercial input and participation in IETF activities... Stastny Richard wrote: > Jeff, > > Just one additional question before I reread the document: > > I am also not reading the company you are always blaming: Nuestar > > Could it be you are talking about Neustar? > > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 6:43 PM > > To: Kevin McCandless > > Cc: enum@ietf.org > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > Global Switched Telephone Network (GSTN): An Overview > > > > > > Kevin and all, > > > > Number portability is not a new technology by any means. > > It has been used in the Military for at least two decades > > that I am aware of and have some experience with. Nuestar is > > not the only company/organization that has broad experience > > in this arena either. > > > > But your right that what this has to do with ENUM is > > anyone's guess, just now... However I can see some > > interesting correlation's here... Hence my concern... So I > > prefer to stay ahead of the curve, so to speak... >;) > > > > Kevin McCandless wrote: > > > > > Jeff: > > > > > > This is a contribution to educate us on Number Portability. > > We should > > > be glad that a company like Neustar understands this > > complex service. > > > What it has to do with ENUM is still anyone's guess. > > > > > > K... > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, February 20, 2003 3:16 AM > > > > To: Jeff Williams; rfc-editor@rfc-editor.org > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; > > > > james.yu@neustar.biz; Jeff Neuman > > > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > Jeff, > > > > I do not read this. > > > > So what is your problem with this informational document? > > > > I there anything wrong in it? > > > > Richard > > > > > > > > > -----Original Message----- > > > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > > > Sent: Thursday, February 20, 2003 7:13 AM > > > > > To: rfc-editor@rfc-editor.org > > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > > > Subject: Re: [Enum] RFC 3482 on Number Portability in > > the Global > > > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > > > > RFC Editor and all, > > > > > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC > > to me. Has > > > > > Nuestar taken over a percentage of the IETF recently? > > > > > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > > > > > A new Request for Comments is now available in online RFC > > > > libraries. > > > > > > > > > > > > RFC 3482 > > > > > > > > > > > > Title: Number Portability in the Global Switched > > > > > > Telephone Network (GSTN): An Overview > > > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > > > Status: Informational > > > > > > Date: February 2003 > > > > > > Mailbox: mark.foster@neustar.biz, > > > > > tom.mcgarry@neustar.biz, > > > > > > james.yu@neustar.biz > > > > > > Pages: 30 > > > > > > Characters: 78552 > > > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > > > > > URL: > > ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > > > > > This document provides an overview of E.164 telephone number > > > > > > portability (NP) in the Global Switched Telephone Network > > > > > > (GSTN). > > > > > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > > > telephony > > > > > > service competition, by enabling end-users to retain > > > > > telephone numbers > > > > > > while changing service providers. NP changes the > > > > > fundamental nature > > > > > > of a dialed E.164 number from a hierarchical physical > > > > > routing address > > > > > > to a virtual address, thereby requiring the transparent > > > > > translation of > > > > > > the later to the former. In addition, there are various > > > > regulatory > > > > > > constraints that establish relevant parameters for NP > > > > > implementation, > > > > > > most of which are not network technology specific. > > > > > Consequently, the > > > > > > implementation of NP behavior consistent with applicable > > > > regulatory > > > > > > constraints, as well as the need for interoperation with > > > > > the existing > > > > > > GSTN NP implementations, are relevant topics for numerous > > > > > areas of IP > > > > > > telephony works-in-progress with the IETF. > > > > > > > > > > > > This document is a product of the Telephone Number > > > > Mapping Working > > > > > > Group of the IETF. > > > > > > > > > > > > This memo provides information for the Internet > > > > community. It does > > > > > > not specify an Internet standard of any kind. > > > > Distribution of this > > > > > > memo is unlimited > > > > > > > > > > > > This announcement is sent to the IETF list and the RFC-DIST > > > > > > list. Requests to be added to or deleted from the IETF > > > > distribution list > > > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > > > added to or > > > > > > deleted from the RFC-DIST distribution list should be sent to > > > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > > > by sending > > > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message > > > > > > body > > > > > > help: ways_to_get_rfcs. For example: > > > > > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > > > Subject: getting rfcs > > > > > > > > > > > > help: ways_to_get_rfcs > > > > > > > > > > > > Requests for special distribution should be addressed to > > > > either the > > > > > > author of the RFC in question, or to > > RFC-Manager@RFC-EDITOR.ORG. > > > > > > Unless specifically noted otherwise on the RFC itself, > > > > all RFCs are > > > > > > for unlimited distribution.echo Submissions for Requests > > > > > for Comments > > > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > > > consult RFC 2223, > > > > > > Instructions to RFC Authors, for further information. > > > > > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > > > USC/Information Sciences Institute > > > > > > > > > > > > ... > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > Mail Reader > > > > > > implementation to automatically retrieve the ASCII version of > > > > > > the RFCs. > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Jeffrey A. Williams > > > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > > > strong!) > > > > > ================================================================ > > > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > > > Information Network Eng. Group. INEG. INC. E-Mail > > > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or > > > > > 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > Regards, > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. E-Mail > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 13:03:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23310 for ; Thu, 20 Feb 2003 13:03:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIA5l02387 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 13:10:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIA4p02382; Thu, 20 Feb 2003 13:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI9Ep02326 for ; Thu, 20 Feb 2003 13:09:15 -0500 Received: from smtp10.atl.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23229 for ; Thu, 20 Feb 2003 13:02:01 -0500 (EST) Received: from dialup-64.152.233.18.dial1.dallas1.level3.net ([64.152.233.18] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 18lv4q-0000LZ-00; Thu, 20 Feb 2003 13:05:45 -0500 Message-ID: <3E553540.96110877@ix.netcom.com> Date: Thu, 20 Feb 2003 12:06:25 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Yu, James" CC: enum@ietf.org Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview References: <25A36E32FDC7D511827600306E1C196201168172@CHLAEXCH1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yu and all, Yu, James wrote: > Jeff, > > I am in CA and just saw the discussions. > > First, this is an informational RFC, so it is not a "standard" such as the > SIP RFC. Yes I understood that clearly. But thank you again for this restatement. > > > NeuStar examined the impacts of NP on many of IETF's current activities and > the potential areas that might be caused by NP. One area was ENUM (that was > why this document was submitted to the enum WG). As indicated by Penn, > NeuStar and AT&T jointly investigated the impact of NP on the ENUM > provisioning process and showed how the provisioning process would be done > if the telephony carriers and the subscribers share the common domain tree > (e.g., e164.arpa). The process became complicate when NP is involved > because the new telephony carrier's NAPTR RRs must be used when the > subscriber (ENUM user or ENUM registrant) changes the telephony carrier. We > recommended that "carrier" ENUM (or "infrastructure" ENUM," - the use of > ENUM by the telephony carriers) use a different domain tree to avoid > involving NP in the ENUM provisioning process. Yes I understood this to be the case when reading this informational RFC. > > > We have identified several other issues such as those related to iptel WG > and convergence. Please see the last section that discusses those issues. I did so. I will likely have further comments to that specific section at a later date, pending some technical investigation. > > > Hope that the above providess the clarifications. Some, yes. > > > James > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Thursday, February 20, 2003 12:43 PM > > To: Kevin McCandless > > Cc: enum@ietf.org > > Subject: Re: [Enum] RFC 3482 on Number Portability in the Global > > Switched Telephone Network (GSTN): An Overview > > > > > > Kevin and all, > > > > Number portability is not a new technology by any means. > > It has been > > used in the Military for at least two decades that I am aware of and > > have some experience with. Nuestar is not the only > > company/organization > > that has broad experience in this arena either. > > > > But your right that what this has to do with ENUM is anyone's > > guess, just now... However I can see some interesting correlation's > > here... Hence my concern... So I prefer to stay ahead of the > > curve, so to speak... >;) > > > > Kevin McCandless wrote: > > > > > Jeff: > > > > > > This is a contribution to educate us on Number Portability. > > We should be > > > glad that a company like Neustar understands this complex > > service. What it > > > has to do with ENUM is still anyone's guess. > > > > > > K... > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, February 20, 2003 3:16 AM > > > > To: Jeff Williams; rfc-editor@rfc-editor.org > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > tom.mcgarry@neustar.biz; > > > > james.yu@neustar.biz; Jeff Neuman > > > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global > > > > Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > Jeff, > > > > I do not read this. > > > > So what is your problem with this informational document? > > > > I there anything wrong in it? > > > > Richard > > > > > > > > > -----Original Message----- > > > > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > > > > Sent: Thursday, February 20, 2003 7:13 AM > > > > > To: rfc-editor@rfc-editor.org > > > > > Cc: enum@ietf.org; mark.foster@neustar.biz; > > > > > tom.mcgarry@neustar.biz; james.yu@neustar.biz; Jeff Neuman > > > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the > > > > > Global Switched Telephone Network (GSTN): An Overview > > > > > > > > > > > > > > > RFC Editor and all, > > > > > > > > > > Looks an awful lot like a Nuestar/IEGF document/RFC to me. > > > > > Has Nuestar taken over a percentage of the IETF recently? > > > > > > > > > > rfc-editor@rfc-editor.org wrote: > > > > > > > > > > > A new Request for Comments is now available in online RFC > > > > libraries. > > > > > > > > > > > > RFC 3482 > > > > > > > > > > > > Title: Number Portability in the Global Switched > > > > > > Telephone Network (GSTN): An Overview > > > > > > Author(s): M. Foster, T. McGarry, J. Yu > > > > > > Status: Informational > > > > > > Date: February 2003 > > > > > > Mailbox: mark.foster@neustar.biz, > > > > > tom.mcgarry@neustar.biz, > > > > > > james.yu@neustar.biz > > > > > > Pages: 30 > > > > > > Characters: 78552 > > > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > > > > > I-D Tag: draft-ietf-enum-e164-gstn-np-05.txt > > > > > > > > > > > > URL: > > ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt > > > > > > > > > > > > This document provides an overview of E.164 telephone number > > > > > > portability (NP) in the Global Switched Telephone > > Network (GSTN). > > > > > > > > > > > > NP is a regulatory imperative seeking to liberalize local > > > > telephony > > > > > > service competition, by enabling end-users to retain > > > > > telephone numbers > > > > > > while changing service providers. NP changes the > > > > > fundamental nature > > > > > > of a dialed E.164 number from a hierarchical physical > > > > > routing address > > > > > > to a virtual address, thereby requiring the transparent > > > > > translation of > > > > > > the later to the former. In addition, there are various > > > > regulatory > > > > > > constraints that establish relevant parameters for NP > > > > > implementation, > > > > > > most of which are not network technology specific. > > > > > Consequently, the > > > > > > implementation of NP behavior consistent with applicable > > > > regulatory > > > > > > constraints, as well as the need for interoperation with > > > > > the existing > > > > > > GSTN NP implementations, are relevant topics for numerous > > > > > areas of IP > > > > > > telephony works-in-progress with the IETF. > > > > > > > > > > > > This document is a product of the Telephone Number > > > > Mapping Working > > > > > > Group of the IETF. > > > > > > > > > > > > This memo provides information for the Internet > > > > community. It does > > > > > > not specify an Internet standard of any kind. > > > > Distribution of this > > > > > > memo is unlimited > > > > > > > > > > > > This announcement is sent to the IETF list and the > > RFC-DIST list. > > > > > > Requests to be added to or deleted from the IETF > > > > distribution list > > > > > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > > > > added to or > > > > > > deleted from the RFC-DIST distribution list should be sent to > > > > > > RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > > > > > > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained > > > > > by sending > > > > > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the > > message body > > > > > > help: ways_to_get_rfcs. For example: > > > > > > > > > > > > To: rfc-info@RFC-EDITOR.ORG > > > > > > Subject: getting rfcs > > > > > > > > > > > > help: ways_to_get_rfcs > > > > > > > > > > > > Requests for special distribution should be addressed to > > > > either the > > > > > > author of the RFC in question, or to > > RFC-Manager@RFC-EDITOR.ORG. > > > > > > Unless specifically noted otherwise on the RFC itself, > > > > all RFCs are > > > > > > for unlimited distribution.echo Submissions for Requests > > > > > for Comments > > > > > > should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please > > > > > consult RFC 2223, > > > > > > Instructions to RFC Authors, for further information. > > > > > > > > > > > > Joyce K. Reynolds and Sandy Ginoza > > > > > > USC/Information Sciences Institute > > > > > > > > > > > > ... > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > Mail Reader > > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > > RFCs. > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Jeffrey A. Williams > > > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders > > > > > strong!) > > > > > ================================================================ > > > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > > > > Information Network Eng. Group. INEG. INC. E-Mail > > > > > jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or > > 214-244-3801 > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > Regards, > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) > > ================================================================ > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 214-244-4827 or 214-244-3801 > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 13:21:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24119 for ; Thu, 20 Feb 2003 13:21:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIScT03482 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 13:28:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KISbp03472; Thu, 20 Feb 2003 13:28:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIRQp03402 for ; Thu, 20 Feb 2003 13:27:26 -0500 Received: from smtp.uc3m.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24041 for ; Thu, 20 Feb 2003 13:20:15 -0500 (EST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8D442431E9; Thu, 20 Feb 2003 19:24:04 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id A04EA99E65; Thu, 20 Feb 2003 19:24:01 +0100 (CET) From: marcelo bagnulo To: paf@cisco.com, michael@neonym.net Cc: enum@ietf.org Content-Type: text/plain Organization: uc3m Message-Id: <1045765436.723.38.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 19:23:57 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] About draft-ietf-enum-rfc2916bis-03 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have a question about draft-ietf-enum-rfc2916bis-03 According to RFC3402 the step 1 of the DDDS algorithm is: "1. The First Well Known Rule is applied to the Application Unique String which produces a Key." According to draft-ietf-enum-rfc2916bis-03 The only DDDS data base defined is the DNS and " The Keys for this database are encoded as domain-names." However, the output of the First well known rule is not a valid domain name, so it is not a valid key. Moreover, the First well known rule is the identity. Wouldm't this be in contradiction with the part of RFC 3402 quoted above? Furthemore, draft-ietf-enum-rfc2916bis-03 specifies in 2.4 an additional algorithm to convert the output of the First Well Known Rule to a Key (DNS name), but I do not see how this algorithm is inlcuded in the general algorithm described in RFC 3402. I guess that the real question is why not define the First Well Known rule as the algorithm to convert an E164 number to a DNS name, including the algorithm currently included in point 2.4 of draft-ietf-enum-rfc2916bis-03? Some editorial comments: I think that there are some typos in the references. For instance, in 2. The ENUM Application Specifications This template defines the ENUM DDDS Application according to the rules and requirements found in [1]. The DDDS database used by this ^^^^^ should be [6]? Application is found in [2] which is the document that defines the ^^^^^ should be 1? NAPTR DNS Resource Record type. Later on 2.4 Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) [2] specifies a DDDS Database that uses the ^^^^ should be 1 Finally, i am not sure which one are normative references but wouldn't reference 6 be normative? (since it is a Standard track RFC) Thanks, -- marcelo bagnulo uc3m _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 13:38:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24739 for ; Thu, 20 Feb 2003 13:38:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIj8805120 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 13:45:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIj7p05115; Thu, 20 Feb 2003 13:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIiQp05051 for ; Thu, 20 Feb 2003 13:44:26 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24657 for ; Thu, 20 Feb 2003 13:37:14 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 20 Feb 2003 00:19:53 -0500 From: Michael Mealling To: marcelo bagnulo Cc: paf@cisco.com, enum@ietf.org In-Reply-To: <1045765436.723.38.camel@presto.it.uc3m.es> References: <1045765436.723.38.camel@presto.it.uc3m.es> Organization: Harriman Heavy Industries, Inc. Message-Id: <1045766210.14266.519.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 20 Feb 2003 13:36:50 -0500 Content-Transfer-Encoding: 7bit Subject: [Enum] Re: About draft-ietf-enum-rfc2916bis-03 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 13:23, marcelo bagnulo wrote: > Hi, > > I have a question about draft-ietf-enum-rfc2916bis-03 > > According to RFC3402 the step 1 of the DDDS algorithm is: > "1. The First Well Known Rule is applied to the Application Unique > String which produces a Key." > > According to draft-ietf-enum-rfc2916bis-03 > > The only DDDS data base defined is the DNS and " The Keys for this database are encoded as domain-names." > However, the output of the First well known rule is not a valid domain name, so it is not a valid key. > Moreover, the First well known rule is the identity. Wouldm't this be in contradiction with the part of RFC 3402 quoted above? Nope. And this is kind of subtle. The First Well Known Rule (FWKR) produces a key that is Database independent. It isn't until you get to the Database Specification section that you actually say how you convert a Key into something that is valid for that particular Database. If it weren't this way then it would be a pain to specify a new Database for ENUM if someone were to do so. > > Furthemore, draft-ietf-enum-rfc2916bis-03 specifies in 2.4 an additional algorithm to convert the output of the First Well Known Rule to a Key (DNS name), > but I do not see how this algorithm is inlcuded in the general algorithm described in RFC 3402. Its in the part of 3402 that is Database dependent. The Keys are the same, they just have to be converted into a format that is valid for whatever Database you are using. > > I guess that the real question is why not define the First Well Known rule as the algorithm to convert an E164 number to a DNS name, > including the algorithm currently included in point 2.4 of draft-ietf-enum-rfc2916bis-03? Because then you'd always be stuck with the DNS database for ENUM when it could be very possible that folks may decide to build a new database for ENUM at some latter date. > Some editorial comments: > > I think that there are some typos in the references. > For instance, in > 2. The ENUM Application Specifications > > This template defines the ENUM DDDS Application according to the > rules and requirements found in [1]. The DDDS database used by this > ^^^^^ should be [6]? > > > Application is found in [2] which is the document that defines the > ^^^^^ should be 1? > > NAPTR DNS Resource Record type. Yep. I've gotten that comment from someone else as well. Thanks. > Later on > > 2.4 Valid Databases > > At present only one DDDS Database is specified for this Application. > "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS > Database" (RFC 3403) [2] specifies a DDDS Database that uses the > ^^^^ should be 1 > > Finally, i am not sure which one are normative references but wouldn't reference 6 be normative? > (since it is a Standard track RFC) Yep. Good catch there too. I'll check the copy that Patrik and I are working on.... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 20 13:50:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25133 for ; Thu, 20 Feb 2003 13:50:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIv9605617 for enum-archive@odin.ietf.org; Thu, 20 Feb 2003 13:57:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIv8p05612; Thu, 20 Feb 2003 13:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIuAp05572 for ; Thu, 20 Feb 2003 13:56:10 -0500 Received: from smtp.uc3m.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25085 for ; Thu, 20 Feb 2003 13:48:57 -0500 (EST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 04031431CA; Thu, 20 Feb 2003 19:52:46 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id E46CB99F53; Thu, 20 Feb 2003 19:52:46 +0100 (CET) From: marcelo bagnulo To: Michael Mealling Cc: paf@cisco.com, enum@ietf.org In-Reply-To: <1045766210.14266.519.camel@blackdell.neonym.net> References: <1045765436.723.38.camel@presto.it.uc3m.es> <1045766210.14266.519.camel@blackdell.neonym.net> Content-Type: text/plain Organization: uc3m Message-Id: <1045767164.723.45.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 19:52:45 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: About draft-ietf-enum-rfc2916bis-03 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Michael, Thanks for such a fast answer. I understand now... However, i am not sure that this is so clear in the specs (at least it wasn't clear to me :-), perhaps it would be interesting to explain this idea of database independent key vs. the key that is actually used. Thanks again, marcelo On Thu, 2003-02-20 at 19:36, Michael Mealling wrote: > On Thu, 2003-02-20 at 13:23, marcelo bagnulo wrote: > > Hi, > > > > I have a question about draft-ietf-enum-rfc2916bis-03 > > > > According to RFC3402 the step 1 of the DDDS algorithm is: > > "1. The First Well Known Rule is applied to the Application Unique > > String which produces a Key." > > > > According to draft-ietf-enum-rfc2916bis-03 > > > > The only DDDS data base defined is the DNS and " The Keys for this database are encoded as domain-names." > > However, the output of the First well known rule is not a valid domain name, so it is not a valid key. > > Moreover, the First well known rule is the identity. Wouldm't this be in contradiction with the part of RFC 3402 quoted above? > > Nope. And this is kind of subtle. The First Well Known Rule (FWKR) > produces a key that is Database independent. It isn't until you get to > the Database Specification section that you actually say how you convert > a Key into something that is valid for that particular Database. If it > weren't this way then it would be a pain to specify a new Database for > ENUM if someone were to do so. > > > > > Furthemore, draft-ietf-enum-rfc2916bis-03 specifies in 2.4 an additional algorithm to convert the output of the First Well Known Rule to a Key (DNS name), > > but I do not see how this algorithm is inlcuded in the general algorithm described in RFC 3402. > > Its in the part of 3402 that is Database dependent. The Keys are the > same, they just have to be converted into a format that is valid for > whatever Database you are using. > > > > > I guess that the real question is why not define the First Well Known rule as the algorithm to convert an E164 number to a DNS name, > > including the algorithm currently included in point 2.4 of draft-ietf-enum-rfc2916bis-03? > > Because then you'd always be stuck with the DNS database for ENUM when > it could be very possible that folks may decide to build a new database > for ENUM at some latter date. > > > Some editorial comments: > > > > I think that there are some typos in the references. > > For instance, in > > 2. The ENUM Application Specifications > > > > This template defines the ENUM DDDS Application according to the > > rules and requirements found in [1]. The DDDS database used by this > > ^^^^^ should be [6]? > > > > > > Application is found in [2] which is the document that defines the > > ^^^^^ should be 1? > > > > NAPTR DNS Resource Record type. > > Yep. I've gotten that comment from someone else as well. Thanks. > > > Later on > > > > 2.4 Valid Databases > > > > At present only one DDDS Database is specified for this Application. > > "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS > > Database" (RFC 3403) [2] specifies a DDDS Database that uses the > > ^^^^ should be 1 > > > > Finally, i am not sure which one are normative references but wouldn't reference 6 be normative? > > (since it is a Standard track RFC) > > Yep. Good catch there too. I'll check the copy that Patrik and I are > working on.... > > -MM -- marcelo bagnulo uc3m _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 21 03:46:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23305 for ; Fri, 21 Feb 2003 03:46:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L8rfQ04265 for enum-archive@odin.ietf.org; Fri, 21 Feb 2003 03:53:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L8rbp04258; Fri, 21 Feb 2003 03:53:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHaSp31585 for ; Thu, 20 Feb 2003 12:36:28 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22225 for ; Thu, 20 Feb 2003 12:29:17 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030220164005.GBFF3860.mailhost.chi1.ameritech.net@repligate>; Thu, 20 Feb 2003 10:40:05 -0600 Message-ID: <1bc701c2d8fe$c743b030$8500a8c0@repligate> From: "Jim Fleming" To: "Yu, James" , "'Jeff Williams'" Cc: References: <25A36E32FDC7D511827600306E1C196201168172@CHLAEXCH1> Subject: Re: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview Date: Thu, 20 Feb 2003 10:40:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Yu, James" > NeuStar and AT&T jointly investigated the impact of NP on the ENUM > provisioning process and showed how the provisioning process would be done > if the telephony carriers and the subscribers share the common domain tree > (e.g., e164.arpa). ==== ...do you really think enlightened people are fooled any more ? http://IPv8.isfun.net http://www.go-mono.com/ http://www.knoppix.com http://www.netfilter.org http://www.digium.com http://www.asterisk.org http://www.openss7.org http://www.zapatatelephony.org http://www.new.net http://IPv8.iscool.net Jim Fleming Inter.C@T.Inter.NAT Consultant http://www.Unir.NET http://www.Unir.com http://www.Uni%ae.com http://www.Uni®.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 21 08:48:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29365 for ; Fri, 21 Feb 2003 08:48:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LDt8d23884 for enum-archive@odin.ietf.org; Fri, 21 Feb 2003 08:55:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDt4p23879; Fri, 21 Feb 2003 08:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDmEp23676 for ; Fri, 21 Feb 2003 08:48:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29182; Fri, 21 Feb 2003 08:40:40 -0500 (EST) Message-Id: <200302211340.IAA29182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 21 Feb 2003 08:40:40 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-02.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --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 : Extensible Provisioning Protocol E.164 Number Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-02.txt Pages : 20 Date : 2003-2-20 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-epp-e164-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-20155104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-epp-e164-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-epp-e164-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-20155104.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Feb 24 06:50:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09380 for ; Mon, 24 Feb 2003 06:50:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OBwVN18908 for enum-archive@odin.ietf.org; Mon, 24 Feb 2003 06:58:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBw2p18897; Mon, 24 Feb 2003 06:58:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBsWp18740 for ; Mon, 24 Feb 2003 06:54:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08882; Mon, 24 Feb 2003 06:45:32 -0500 (EST) Message-Id: <200302241145.GAA08882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org, iptel@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Feb 2003 06:45:32 -0500 Subject: [Enum] I-D ACTION:draft-brandner-enumservice-vovi-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration for enumservices voice and video Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-vovi-00.txt Pages : 0 Date : 2003-2-21 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the 'enumservices' registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-vovi-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brandner-enumservice-vovi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brandner-enumservice-vovi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21161141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enumservice-vovi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enumservice-vovi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21161141.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Feb 24 10:30:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16769 for ; Mon, 24 Feb 2003 10:30:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OFcvN00766 for enum-archive@odin.ietf.org; Mon, 24 Feb 2003 10:38:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFclp00758; Mon, 24 Feb 2003 10:38:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFbap00715 for ; Mon, 24 Feb 2003 10:37:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16690 for ; Mon, 24 Feb 2003 10:28:30 -0500 (EST) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by ietf-mx.ietf.org (8.11.6+Sun/8.11.6) with ESMTP id h1OFEha02542 for ; Mon, 24 Feb 2003 10:14:43 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA04147 for ; Mon, 24 Feb 2003 07:32:06 -0800 Message-Id: <5.2.0.9.2.20030224102904.059a8dc8@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Feb 2003 10:29:31 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-toyoda-faxservice-enum-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-toyoda-faxservice-enum-00.txt >Date: Mon, 24 Feb 2003 06:44:38 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IFAX service of ENUM > Author(s) : K. Toyoda, D. Crocker > Filename : draft-toyoda-faxservice-enum-00.txt > Pages : 0 > Date : 2003-2-21 > >This document describes the functional specification >and the definition of the ENUM NAPTR record, for IFax >service. IFax is 'Facsimile using Internet Mail'. For >this use, the DNS returns the email address of the >referenced IFax system. This mechanism allows email-based >fax communication to use telephone numbers, rather than >requiring that the sender already know the recipient >email address. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-toyoda-faxservice-enum-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-toyoda-faxservice-enum-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-toyoda-faxservice-enum-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-21161024.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-toyoda-faxservice-enum-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Feb 24 10:30:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16785 for ; Mon, 24 Feb 2003 10:30:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OFcxR00795 for enum-archive@odin.ietf.org; Mon, 24 Feb 2003 10:38:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFcxp00790; Mon, 24 Feb 2003 10:38:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFbap00718 for ; Mon, 24 Feb 2003 10:37:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16692 for ; Mon, 24 Feb 2003 10:28:30 -0500 (EST) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by ietf-mx.ietf.org (8.11.6+Sun/8.11.6) with ESMTP id h1OFEha02543 for ; Mon, 24 Feb 2003 10:14:43 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA04153 for ; Mon, 24 Feb 2003 07:32:06 -0800 Message-Id: <5.2.0.9.2.20030224103038.05aa9e10@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Feb 2003 10:31:34 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: [Iptel] I-D ACTION:draft-brandner-enum-uri-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI... as the AD's directed after Atlanta this document will be worked through the IPTEL WG >X-Envelope-To: >To: IETF-Announce: ; >CC: iptel@ietf.org, mpls@uu.net >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: [Iptel] I-D ACTION:draft-brandner-enum-uri-01.txt >Sender: iptel-admin@ietf.org >X-BeenThere: iptel@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: IP Telephony >List-Post: >List-Help: >List-Subscribe: , > >List-Archive: >Date: Mon, 24 Feb 2003 06:46:09 -0500 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The 'enum:' URI scheme > Author(s) : R. Brandner, L. Conroy, R. Stastny > Filename : draft-brandner-enum-uri-01.txt > Pages : 6 > Date : 2003-2-21 > >This document specifies the enum: URI scheme. This URI is intended for >use where a resource address can be returned by evaluating the URI value >using the ENUM DDDS application. Syntactically, it uses a subset of the >format defined for the tel: URI scheme. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-brandner-enum-uri-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-brandner-enum-uri-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-21161217.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-brandner-enum-uri-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Feb 25 23:58:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28658 for ; Tue, 25 Feb 2003 23:58:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q57jN29594 for enum-archive@odin.ietf.org; Wed, 26 Feb 2003 00:07:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q57Mp29435; Wed, 26 Feb 2003 00:07:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q55ip28776 for ; Wed, 26 Feb 2003 00:05:44 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28639 for ; Tue, 25 Feb 2003 23:55:52 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA05292; Tue, 25 Feb 2003 20:59:28 -0800 Message-Id: <5.2.0.9.2.20030225235546.01604f48@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 25 Feb 2003 23:58:13 -0500 To: "Toyoda, Kiyoshi" From: Richard Shockey Cc: ietf-fax@imc.org, enum@ietf.org In-Reply-To: <200302260258.AA02467@d23n59.jp.panasonic.com> References: <5.2.0.9.2.20030224110427.05a06168@popd.ix.netcom.com> <5.2.0.9.2.20030224110427.05a06168@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Re: ENUM faxservice registration... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 11:58 AM 2/26/2003 +0900, Toyoda, Kiyoshi wrote: >Shockey-san, > >Richard Shockey wrote: > > > > > >IMHO this looks excellent .. in fact a model for how such a registration > >document should be structured. > >Thank you. > > > > >Dave, Toyoda-san do you want any time at the ENUM WG ? > >Thank you for your kind offer. Would you give me 5 minutes? I'd be delighted ... I'll cross post the agenda for the ENUM WG when I have it ready. > > > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-toyoda-faxservice-enum-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Feb 26 15:44:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24434 for ; Wed, 26 Feb 2003 15:44:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QKs1U09351 for enum-archive@odin.ietf.org; Wed, 26 Feb 2003 15:54:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKrlp09334; Wed, 26 Feb 2003 15:53:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKqxp09279 for ; Wed, 26 Feb 2003 15:52:59 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24391 for ; Wed, 26 Feb 2003 15:42:48 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA11071 for ; Wed, 26 Feb 2003 12:46:25 -0800 Message-Id: <5.2.0.9.2.20030224104207.05a06168@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Feb 2003 15:45:22 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QKqxp09280 Subject: [Enum] Probable Agenda for IETF 56 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We have been changed to WED ... we now have a 2 1/2 hr slot .. I want to knock out easy stuff first ..before we get into the heart of the matter ..2916 04 is in process. Did I miss anything... Ok who want to volunteer for scribe ..... WEDNESDAY, March 19, 2003 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG OPS v6ops IPv6 Operations WG TSV dccp Datagram Congestion Control Protocol WG TSV enum Telephone Number Mapping WG ************* IETF 56 San Francisco Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … VOLUNTEERS WANTED ! . ################### 1 . 2916bis 04 review... Patrik Faltstrom 10 M ?? ################# 2. Report from the IFAX WG Toyoda-san 10 M Title : IFAX service of ENUM Author(s) : K. Toyoda, D. Crocker Filename : draft-toyoda-faxservice-enum-00.txt Pages : 0 Date : 2003-2-21 This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-toyoda-faxservice-enum-00.txt ################### 3. Presence service registration Jon Peterson 20 Min coming ################### 4 Brandner etal 1 hr. Title : Registration for enumservices of group messages Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enumservice-msg-00.txt Pages : 0 Date : 2003-2-11 This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-msg-00.txt Titile ; : Registration for enumservices voice and video Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-vovi-00.txt Pages : 0 Date : 2003-2-21 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the 'enumservices' registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-vovi-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration for enumservices web and ft Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-webft-00.txt Pages : 0 Date : 2003-2-24 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-webft-00.txt ################### Additional ENUM WG documents that have revised versions but not on the agenda... A. Peterson SIP enumservice registrations. B. Title : ENUM Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-ietf-enum-h323-00.txt Pages : 4 Date : 2003-2-19 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-00.txt C. Title : Extensible Provisioning Protocol E.164 Number Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-02.txt Pages : 20 Date : 2003-2-20 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-02.txt D. Privacy and Security .. E. ENUM Call flows... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 27 07:46:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28003 for ; Thu, 27 Feb 2003 07:46:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCuGg14730 for enum-archive@odin.ietf.org; Thu, 27 Feb 2003 07:56:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCttp14699; Thu, 27 Feb 2003 07:55:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCrfp14473 for ; Thu, 27 Feb 2003 07:53:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27238; Thu, 27 Feb 2003 07:43:11 -0500 (EST) Message-Id: <200302271243.HAA27238@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:43:11 -0500 Subject: [Enum] I-D ACTION:draft-peterson-enum-pres-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enumservice Registration for Presence Services Author(s) : J. Peterson Filename : draft-peterson-enum-pres-00.txt Pages : 8 Date : 2003-2-26 This document registers an ENUM service for presence services (as described in RFC2778 [3]) pursuant to the guidelines in RFC2916bis [2]. Specifically, this document focuses on provisioning pres URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-enum-pres-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-enum-pres-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-enum-pres-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-enum-pres-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-enum-pres-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160455.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 27 07:51:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28408 for ; Thu, 27 Feb 2003 07:51:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RD1Z615295 for enum-archive@odin.ietf.org; Thu, 27 Feb 2003 08:01:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RD1Yp15290; Thu, 27 Feb 2003 08:01:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCuDp14722 for ; Thu, 27 Feb 2003 07:56:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27951; Thu, 27 Feb 2003 07:45:42 -0500 (EST) Message-Id: <200302271245.HAA27951@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:45:42 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-sip-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --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 : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-ietf-enum-sip-00.txt Pages : 9 Date : 2003-2-26 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-sip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-sip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26161020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-sip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-sip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26161020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Feb 27 08:57:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02912 for ; Thu, 27 Feb 2003 08:57:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RE7lI21584 for enum-archive@odin.ietf.org; Thu, 27 Feb 2003 09:07:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RE7fp21564; Thu, 27 Feb 2003 09:07:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RE6Sp20785 for ; Thu, 27 Feb 2003 09:06:28 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02859 for ; Thu, 27 Feb 2003 08:55:56 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA01020; Thu, 27 Feb 2003 14:59:50 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA00928; Thu, 27 Feb 2003 14:59:50 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1Z1MR18C>; Thu, 27 Feb 2003 14:58:59 +0100 Message-ID: From: Brandner Rudolf To: "'Richard Shockey'" Cc: enum@ietf.org Subject: RE: [Enum] Probable Agenda for IETF 56 Date: Thu, 27 Feb 2003 14:58:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Richard, agenda looks good. Go for it. have a nice day, Rudi > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Mittwoch, 26. Februar 2003 21:45 > To: enum@ietf.org > Subject: [Enum] Probable Agenda for IETF 56 > > > > We have been changed to WED ... we now have a 2 1/2 hr slot .. > > I want to knock out easy stuff first ..before we get into the > heart of the > matter ..2916 04 is in process. > > Did I miss anything... > > Ok who want to volunteer for scribe ..... > > > WEDNESDAY, March 19, 2003 > 0800-1700 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > APP calsch Calendaring and Scheduling WG > OPS v6ops IPv6 Operations WG > TSV dccp Datagram Congestion Control Protocol WG > TSV enum Telephone Number Mapping WG > > ************* > > IETF 56 San Francisco Telephone Number Mapping (ENUM) WG Agenda > > Chair(s): > Patrik Faltstrom > Richard Shockey > > > Transport Area Advisor: > Scott Bradner > > Mailing Lists: > General Discussion:enum@ietf.org > To Subscribe: enum-request@ietf.org > In Body: subscribe > Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ > > > AGENDA BASHING (5 min) > > Scribe Introduction ... VOLUNTEERS WANTED ! > . > ################### > 1 . 2916bis 04 review... Patrik Faltstrom 10 M ?? > > > ################# > > 2. Report from the IFAX WG > Toyoda-san 10 M > > > Title : IFAX service of ENUM > Author(s) : K. Toyoda, D. Crocker > Filename : draft-toyoda-faxservice-enum-00.txt > Pages : 0 > Date : 2003-2-21 > > This document describes the functional specification > and the definition of the ENUM NAPTR record, for IFax > service. IFax is 'Facsimile using Internet Mail'. For > this use, the DNS returns the email address of the > referenced IFax system. This mechanism allows email-based > fax communication to use telephone numbers, rather than > requiring that the sender already know the recipient > email address. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-toyoda-faxservice-en > um-00.txt > > > > ################### > 3. Presence service registration Jon Peterson 20 Min > > coming > > > ################### > 4 Brandner etal 1 hr. > > Title : Registration for enumservices of > group messages > Author(s) : R. Brandner, L. Conroy, R. Stastny > Filename : draft-brandner-enumservice-msg-00.txt > Pages : 0 > Date : 2003-2-11 > > This document registers a group of 'enumservices' [5] to be used to > indicate that the associated resources are capable of receiving > discrete messages. > Specifically, the 'enumservices' registered with this document are > 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes > 'mailto:' and 'tel:' > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brandner-enumservice > -msg-00.txt > > Titile ; : Registration for enumservices > voice and video > Author(s) : R. Brandner et al. > Filename : draft-brandner-enumservice-vovi-00.txt > Pages : 0 > Date : 2003-2-21 > > This document registers a group of 'enumservices' [2] to be used to > indicate that the associated resources are capable of interactive > media stream exchange. > Specifically, the 'enumservices' registered with this document are > 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and > 'tel:'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brandner-enumservice > -vovi-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Registration for enumservices web and ft > Author(s) : R. Brandner et al. > Filename : draft-brandner-enumservice-webft-00.txt > Pages : 0 > Date : 2003-2-24 > > This document registers a group of 'enumservices' [2] to be used to > indicate that the associated resources are primarily sources for > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brandner-enumservice > -webft-00.txt > > > > > ################### > > Additional ENUM WG documents that have revised versions but > not on the > agenda... > > > A. Peterson SIP enumservice registrations. > > B. Title : ENUM Service Registration for H.323 URL > Author(s) : O. Levin > Filename : draft-ietf-enum-h323-00.txt > Pages : 4 > Date : 2003-2-19 > > The H.323 specification [2] defines a means for building multimedia > communication services over an arbitrary Packet Based Network, > including the Internet. This document registers an ENUM service for > H.323 according to specifications and guidelines in RFC2916bis [3]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-00.txt > > > C. Title : Extensible Provisioning Protocol > E.164 Number Mapping > Author(s) : S. Hollenbeck > Filename : draft-ietf-enum-epp-e164-02.txt > Pages : 20 > Date : 2003-2-20 > > This document describes an Extensible Provisioning Protocol > (EPP) extension mapping for the provisioning and management of E.164 > numbers representing domain names stored in a shared central > repository. Specified in XML, this mapping extends the EPP domain > name mapping to provide additional features required for the > provisioning of E.164 numbers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-02.txt > > > D. Privacy and Security .. > > E. ENUM Call flows... > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Feb 28 11:44:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04231 for ; Fri, 28 Feb 2003 11:44:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGtSQ10354 for enum-archive@odin.ietf.org; Fri, 28 Feb 2003 11:55:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGtAp10338; Fri, 28 Feb 2003 11:55:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGrCp10248 for ; Fri, 28 Feb 2003 11:53:12 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04172 for ; Fri, 28 Feb 2003 11:42:08 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id E755E137F0F; Fri, 28 Feb 2003 08:46:03 -0800 (PST) To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Michael Mealling , Stastny Richard , enum@ietf.org Subject: Re: [Enum] On the question of DNSSEC and recommended In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Wed, 19 Feb 2003 08:59:39 +0100." <18BB313D-43E0-11D7-828E-0003934B2128@cisco.com> Date: Fri, 28 Feb 2003 08:46:03 -0800 Message-ID: <58809.1046450763@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Just about coming up for air.... Patrik, I share your concerns about what we put into 2916bis given that DNSSEC isn't quite done yet and the key management stuff is even further away. However I'd prefer if we stuck to the earlier text. (Trials MAY want to use DNSSEC and it will become mandatory if/when DNSSEC is finalised.) We seemed to have reached consensus on that. Your proposed text considerably waters down that recommendation IMO. This gives me a problem as it implies we're backing off from DNSSEC. For ENUM this is a Bad Thing since DNSSEC is the only game in town in the forseeable future for validating DNS packets. And saying an ENUM service SHOULD (only should???) include validation of DNS packets is just far too half-hearted. ENUM will die (or never be born) if there's no way to prevent or detect DNS spoofing under e164.arpa. In my capacity as an ENUM trial manager, I have a further problem with the new text. It will make it harder for me to encourage or persuade folk to introduce DNSSEC into the trial. If there's push back on that, I'd like to point the nay-sayers at an IETF or IAB document which says that DNSSEC is important for ENUM and should figure in trials if possible. Now if that isn't appropriate for 2916bis, it needs to be said somewhere else. Where? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum