From itu+ietf-admin@ietf.org Fri Feb 4 11:30:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01801 for ; Fri, 4 Feb 2000 11:30:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02452 for ; Fri, 4 Feb 2000 11:29:18 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01795; Fri, 4 Feb 2000 11:30:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02375; Fri, 4 Feb 2000 11:28:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02354 for ; Fri, 4 Feb 2000 11:28:25 -0500 (EST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01758; Fri, 4 Feb 2000 11:29:49 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA23516; Fri, 4 Feb 2000 10:29:50 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA00244; Fri, 4 Feb 2000 10:30:21 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:29:35 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:29:34 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDCF@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 11:29:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Randy Bush [mailto:randy@psg.com] wrote: > > I understand that "e164.int" might become a new global TLD, > but what do mean > > the digits of the E.164 number as they are i.e separated by > a dot and > > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > > addresses. > > it is the phone number reversed and the dots are added in a > way that allows > dns delegation at any level in that phone number. e.g. > > phone number is +1 206 780 0431 > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > this allows the dns 'owner' of > > 6.0.2.1.e164.int > > (+1 206 all of the seattle area) to delegate > > 0.8.7.6.0.2.1.e164.int > > to the server set which just handles +1 206 780, bainbridge island. > > this is so it distributes well and hence scales well. True, and the reverse order is used because, as Steven Lind pointed out, the hierarchy in the names is opposite that of the E.164 numbers (and also opposite that of the IP addresses, I might add). However, it's not clear to me why the fields of the E.164 number which are clearly delineated, such as country code and city/area code, could not at least have been kept together, delimited by dots. The long series of dots seems a bit excessive? One might _also_ argue that as long as e164.int is used in the DNS name field, the convention for the stuff up front be in accordance with E.164? I think it would be far clearer, and no tremendous problem, to show +1 206 780 0431 as 1.206.7800431.e164.int, and a euro-style number like 39 06 3295887 as 39.06.3295887.e164.int. I mean, the whole point of DNS names was that they be clear to a human, yes? I still think, though, that using the DNS field for AESAs, peer to the IP address field, would be a useful feature in addition to this naming convention. Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 11:33:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01905 for ; Fri, 4 Feb 2000 11:33:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02748 for ; Fri, 4 Feb 2000 11:32:04 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01900; Fri, 4 Feb 2000 11:33:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02686; Fri, 4 Feb 2000 11:31:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02650 for ; Fri, 4 Feb 2000 11:31:33 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01884; Fri, 4 Feb 2000 11:32:56 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GlfB-0004VN-00; Fri, 04 Feb 2000 08:32:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: enum@ietf.org, itu+ietf@ietf.org References: <4102273CEB77D211869200805FE6F59356EDCF@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 08:32:53 -0800 Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However, it's not clear to me why the fields of the E.164 number which are > clearly delineated, such as country code and city/area code, could not at > least have been kept together, delimited by dots. The long series of dots > seems a bit excessive? because only north americans think country codes and city codes are clearly delineatable in a universal way? randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 11:37:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02022 for ; Fri, 4 Feb 2000 11:37:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02981 for ; Fri, 4 Feb 2000 11:35:45 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02017; Fri, 4 Feb 2000 11:37:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02887; Fri, 4 Feb 2000 11:35:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02863 for ; Fri, 4 Feb 2000 11:35:13 -0500 (EST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02000; Fri, 4 Feb 2000 11:36:37 -0500 (EST) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA28707; Fri, 4 Feb 2000 10:36:38 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA06979; Fri, 4 Feb 2000 10:37:09 -0600 (CST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:36:18 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:36:17 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD0@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 11:36:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Randy Bush [mailto:randy@psg.com] wrote: > > However, it's not clear to me why the fields of the E.164 > number which are > > clearly delineated, such as country code and city/area > code, could not at > > least have been kept together, delimited by dots. The long > series of dots > > seems a bit excessive? > > because only north americans think country codes and city > codes are clearly > delineatable in a universal way? Not so. That's what I tried to point out using the European number example. And if some E.164 number in the future becomes hierarched(??), you can always add in dots. The result will never be ambiguous. Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 11:40:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02191 for ; Fri, 4 Feb 2000 11:40:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03169 for ; Fri, 4 Feb 2000 11:39:14 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02186; Fri, 4 Feb 2000 11:40:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03092; Fri, 4 Feb 2000 11:38:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03072 for ; Fri, 4 Feb 2000 11:38:44 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02156; Fri, 4 Feb 2000 11:40:07 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA29144; Fri, 4 Feb 2000 08:39:44 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id IAA29609; Fri, 4 Feb 2000 08:40:07 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 08:39:56 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:39:55 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD1@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 11:39:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Manfredi, Albert E [mailto:Albert.Manfredi@phl.boeing.com] wrote: > > because only north americans think country codes and city > > codes are clearly > > delineatable in a universal way? > > Not so. That's what I tried to point out using the European > number example. > > And if some E.164 number in the future becomes hierarched(??), you can > always add in dots. The result will never be ambiguous. What I meant was, "And if some E.164 number in the future becomes even _more_ hierarched, ..." Adding dots, as long as the numbers are in consistent order, is no problem at all. Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 11:46:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02384 for ; Fri, 4 Feb 2000 11:46:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03428 for ; Fri, 4 Feb 2000 11:44:46 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02379; Fri, 4 Feb 2000 11:46:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03340; Fri, 4 Feb 2000 11:43:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03312 for ; Fri, 4 Feb 2000 11:43:55 -0500 (EST) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02326; Fri, 4 Feb 2000 11:45:17 -0500 (EST) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA04270; Fri, 4 Feb 2000 11:44:19 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA00636; Fri, 4 Feb 2000 11:44:22 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1JCTTPB7>; Fri, 4 Feb 2000 11:41:06 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF20888E@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Manfredi, Albert E'" , "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 11:44:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org This whole thing starts to fall apart when LNP is introduced. If the EU ever mandated LNP between countries, even that would break down. I guess the issue is: we know that the structure of E.164 is breaking down, we can only speculate how fast it disintegrates. We know that it eventually disintegrates into a data dip on the entire E.164, so should ENUM define something that works for some undefined interim time period or not? If we decide that it should optimize some level of structure, how deep should it go? It seems to me that it is NOT a good idea to have something between 2.1.2.1.5.5.5.2.1.2.1.e164.int and 12125551212.e164.int, because as the structure disintegrates, both mechanisms continue to work, but an intermediate one -- say 5551212.212.1.e164.int -- fails when cross area code LNP is mandated. The problem is that even if the DNS were reorganized, the CLIENTS would have to be reprogrammed, since they have to know to form the query as, say 2125551212.1.e164.int. Not a good plan IMO. Brian > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, February 04, 2000 11:30 AM > To: 'Randy Bush' > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [Enum] Re: Structure of DNS entry for ENUM > > > Randy Bush [mailto:randy@psg.com] wrote: > > > > I understand that "e164.int" might become a new global TLD, > > but what do mean > > > the digits of the E.164 number as they are i.e separated by > > a dot and > > > therefore, I suppose, having to point out INDIVIDUALLY to > certain IP > > > addresses. > > > > it is the phone number reversed and the dots are added in a > > way that allows > > dns delegation at any level in that phone number. e.g. > > > > phone number is +1 206 780 0431 > > > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > > > this allows the dns 'owner' of > > > > 6.0.2.1.e164.int > > > > (+1 206 all of the seattle area) to delegate > > > > 0.8.7.6.0.2.1.e164.int > > > > to the server set which just handles +1 206 780, bainbridge island. > > > > this is so it distributes well and hence scales well. > > True, and the reverse order is used because, as Steven Lind > pointed out, the > hierarchy in the names is opposite that of the E.164 numbers (and also > opposite that of the IP addresses, I might add). > > However, it's not clear to me why the fields of the E.164 > number which are > clearly delineated, such as country code and city/area code, > could not at > least have been kept together, delimited by dots. The long > series of dots > seems a bit excessive? > > One might _also_ argue that as long as e164.int is used in > the DNS name > field, the convention for the stuff up front be in accordance > with E.164? > > I think it would be far clearer, and no tremendous problem, to show > > +1 206 780 0431 > > as 1.206.7800431.e164.int, > > and a euro-style number like > > 39 06 3295887 as > > 39.06.3295887.e164.int. > > I mean, the whole point of DNS names was that they be clear > to a human, yes? > > I still think, though, that using the DNS field for AESAs, > peer to the IP > address field, would be a useful feature in addition to this naming > convention. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 11:53:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02551 for ; Fri, 4 Feb 2000 11:53:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04003 for ; Fri, 4 Feb 2000 11:52:02 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02546; Fri, 4 Feb 2000 11:53:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03813; Fri, 4 Feb 2000 11:51:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03791 for ; Fri, 4 Feb 2000 11:51:27 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02538; Fri, 4 Feb 2000 11:52:50 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayt15777; Fri, 4 Feb 2000 16:52:49 GMT Message-ID: <389B048B.7B4ACD08@dynamicsoft.com> Date: Fri, 04 Feb 2000 11:55:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org References: <4102273CEB77D211869200805FE6F59356EDD0@xch-phl-01.he.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] Re: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > Randy Bush [mailto:randy@psg.com] wrote: > > > > However, it's not clear to me why the fields of the E.164 > > number which are > > > clearly delineated, such as country code and city/area > > code, could not at > > > least have been kept together, delimited by dots. The long > > series of dots > > > seems a bit excessive? > > > > because only north americans think country codes and city > > codes are clearly > > delineatable in a universal way? > > Not so. That's what I tried to point out using the European number example. > > And if some E.164 number in the future becomes hierarched(??), you can > always add in dots. The result will never be ambiguous. This is unworkable, IMHO. It requires the clients of the system to have knowledge of the numbering plan for every single country. The dot-between-each-digit moves this knowledge into the DNS zone delegations, which is where it belongs. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 12:01:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02812 for ; Fri, 4 Feb 2000 12:01:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04708 for ; Fri, 4 Feb 2000 12:00:17 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02807; Fri, 4 Feb 2000 12:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04438; Fri, 4 Feb 2000 11:59:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04409 for ; Fri, 4 Feb 2000 11:59:55 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02785; Fri, 4 Feb 2000 12:01:18 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA27583; Fri, 4 Feb 2000 09:00:56 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id JAA20066; Fri, 4 Feb 2000 09:01:13 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 09:01:04 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 12:01:02 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD2@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Jonathan Rosenberg'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 12:01:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] wrote: > > And if some E.164 number in the future becomes > > even more hierarched(??), you can > > always add in dots. The result will never be ambiguous. > > This is unworkable, IMHO. It requires the clients of the > system to have > knowledge of the numbering plan for every single country. The > dot-between-each-digit moves this knowledge into the DNS zone > delegations, which is where it belongs. I guess I'm baffled by this statement. Domain names don't have to be all in identical hierarchy. I can have a machine called engr.boeing.com and another one called engr.arl.boeing.com, and no one will bat an eye. Simlarly, I can have a phone number-made-name show up as 1.703.4126735.e164.int and another one 39.06.3295887.e164.int and in some other country's scheme perhaps 123.06.329.528076.e164.int As long as the e.164 number itself is consistent within e.164, the DNS name should never present a problem. Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 12:20:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03535 for ; Fri, 4 Feb 2000 12:20:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05661 for ; Fri, 4 Feb 2000 12:19:04 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03529; Fri, 4 Feb 2000 12:20:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05622; Fri, 4 Feb 2000 12:18:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05573 for ; Fri, 4 Feb 2000 12:18:51 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03519; Fri, 4 Feb 2000 12:20:15 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayv17575; Fri, 4 Feb 2000 17:20:15 GMT Message-ID: <389B0AFA.838A1EDB@dynamicsoft.com> Date: Fri, 04 Feb 2000 12:23:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: enum@ietf.org, itu+ietf@ietf.org References: <4102273CEB77D211869200805FE6F59356EDD2@xch-phl-01.he.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] Re: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > I guess I'm baffled by this statement. > > Domain names don't have to be all in identical hierarchy. I can have a > machine called engr.boeing.com and another one called engr.arl.boeing.com, > and no one will bat an eye. > > Simlarly, I can have a phone number-made-name show up as > > 1.703.4126735.e164.int > > and another one > > 39.06.3295887.e164.int > > and in some other country's scheme perhaps > > 123.06.329.528076.e164.int > > As long as the e.164 number itself is consistent within e.164, the DNS name > should never present a problem. You are presuming that the form in which the numbers are entered or accessed by users already has these dots. This means that when users enter numbers, they must know the numbering plan of the country for the numbers they enter, or the software must know the numbering plan in order to place the dots into just a digit sequence entered by a user. Both of these are unworkable. End users cannot be expected to have to correctly enter the dots in phone numbers. Today, in the PSTN, I do not need to enter in these separators. When I call Belarus, I enter "375172214841" after the international dial prefix (011). I have NO IDEA what the breakdown of this number is. Having the software do the breakdown is also unworkable. It means the software in a standalone phone would need to be configured with the worlds numbering plans. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 12:37:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04195 for ; Fri, 4 Feb 2000 12:37:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06316 for ; Fri, 4 Feb 2000 12:36:20 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04190; Fri, 4 Feb 2000 12:37:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06255; Fri, 4 Feb 2000 12:36:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06236 for ; Fri, 4 Feb 2000 12:36:13 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04178; Fri, 4 Feb 2000 12:37:36 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA14639; Fri, 4 Feb 2000 09:37:14 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id JAA03890; Fri, 4 Feb 2000 09:37:34 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 09:37:02 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 12:37:00 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Jonathan Rosenberg'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 12:36:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] wrote: > You are presuming that the form in which the numbers are entered or > accessed by users already has these dots. This means that when users > enter numbers, they must know the numbering plan of the > country for the > numbers they enter, or the software must know the numbering plan in > order to place the dots into just a digit sequence entered by a user. > Both of these are unworkable. End users cannot be expected to have to > correctly enter the dots in phone numbers. Today, in the > PSTN, I do not > need to enter in these separators. When I call Belarus, I enter > "375172214841" after the international dial prefix (011). I > have NO IDEA > what the breakdown of this number is. Guys, look. Within the e.164 scheme, people have _never_ truly needed to know the hierarchy. It is only there as a mnemonic aid, fundamentally. Which only makes this problem easier, not harder. If I give out my phone number as 1.703.4126735, a client elsewhere can use that hierarchy, but he doesn't _have_ to. He can just dial the digits. So if I write the DNS name as 1.703.4126735.e164.int, ultimately that number will be used by a public phone system. The phone system, when it sees e164.int, knows full well that the dots between the numbers are utterly irrelevant anyway. They are there just as a mnemonic aid. Perhaps it would help if we establish this simple rule within DNS servers: For all names in the e.164.int domain, the dot symbols to the left of "e164" are ignored if used. Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 12:39:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04298 for ; Fri, 4 Feb 2000 12:39:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06444 for ; Fri, 4 Feb 2000 12:38:27 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04290; Fri, 4 Feb 2000 12:39:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06389; Fri, 4 Feb 2000 12:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06364 for ; Fri, 4 Feb 2000 12:38:20 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04283; Fri, 4 Feb 2000 12:39:43 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Gmhq-0004xY-00; Fri, 04 Feb 2000 09:39:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: "'Jonathan Rosenberg'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 09:39:42 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Perhaps it would help if we establish this simple rule within DNS servers: > > For all names in the e.164.int domain, the dot symbols to the left of "e164" > are ignored if used. ROFL! _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 12:56:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04790 for ; Fri, 4 Feb 2000 12:56:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06883 for ; Fri, 4 Feb 2000 12:55:29 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04785; Fri, 4 Feb 2000 12:56:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06828; Fri, 4 Feb 2000 12:55:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06792 for ; Fri, 4 Feb 2000 12:55:02 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04771; Fri, 4 Feb 2000 12:56:27 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Gmxy-00054M-00; Fri, 04 Feb 2000 09:56:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" , "'Jonathan Rosenberg'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD3@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 09:56:22 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> Perhaps it would help if we establish this simple rule within DNS >> servers: For all names in the e.164.int domain, the dot symbols to the >> left of "e164" are ignored if used. > ROFL! a friend pointed out that i could have been less terse. :-) the first problem is that it would be exceedingly unlikely that dns protocol folk would be at all sympathetic with special hacks for some specific domain as there would soon be 1,000 specific donains that wanted special treatment. but this does not even work for the one domain. it directly implies that the entire domain for all of planet earth is flat and in a single zone file. this is the opposite of 'rational' as used in internet design. randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 13:07:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05170 for ; Fri, 4 Feb 2000 13:07:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07407 for ; Fri, 4 Feb 2000 13:05:45 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05163; Fri, 4 Feb 2000 13:07:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07343; Fri, 4 Feb 2000 13:05:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07319 for ; Fri, 4 Feb 2000 13:05:38 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05157; Fri, 4 Feb 2000 13:07:03 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA25687; Fri, 4 Feb 2000 10:06:39 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA10481; Fri, 4 Feb 2000 10:07:01 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 10:06:45 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 13:06:43 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Fri, 4 Feb 2000 13:06:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Randy Bush [mailto:randy@psg.com] wrote > a friend pointed out that i could have been less terse. :-) > > the first problem is that it would be exceedingly unlikely > that dns protocol > folk would be at all sympathetic with special hacks for some > specific domain > as there would soon be 1,000 specific donains that wanted > special treatment. > > but this does not even work for the one domain. it directly > implies that > the entire domain for all of planet earth is flat and in a > single zone file. > this is the opposite of 'rational' as used in internet design. Fair enough. The point is, when you dial an international number, you the client in fact know full well that there is a country code (at very least). So _that_ much can be delimeted by a dot without undue hardship. All countries also use a city/area code of some kind. It's not too much to ask to delimit that as well. What I think is truly "unworkable" (a favorite word here) is the current plan, which requires every normal human to write down the phone number on a piece of paper before being able to type it in, in reverse order, with all the dots. Business cards show international phone numbers with some semblance of hierarchy. Country code alone might be enough? Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 13:10:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05263 for ; Fri, 4 Feb 2000 13:10:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07562 for ; Fri, 4 Feb 2000 13:08:40 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05256; Fri, 4 Feb 2000 13:10:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07503; Fri, 4 Feb 2000 13:08:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07481 for ; Fri, 4 Feb 2000 13:08:34 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05244; Fri, 4 Feb 2000 13:09:59 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GnB8-0005AX-00; Fri, 04 Feb 2000 10:09:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manfredi, Albert E" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> Message-Id: Date: Fri, 04 Feb 2000 10:09:58 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. nope. as the rule is exceedingly simple, o have full country+city+local number o reverse the order of the digits o put a dot between each one o append .foo.bar clients can do it simply, coded once, and work universally. this same hack has worked for tpc.int for many years. randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 13:18:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05467 for ; Fri, 4 Feb 2000 13:18:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07867 for ; Fri, 4 Feb 2000 13:17:18 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05462; Fri, 4 Feb 2000 13:18:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07774; Fri, 4 Feb 2000 13:15:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07753 for ; Fri, 4 Feb 2000 13:15:49 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05432; Fri, 4 Feb 2000 13:17:13 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA17811; Fri, 4 Feb 2000 13:17:21 -0500 (EST) Message-Id: <200002041817.NAA17811@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Manfredi, Albert E" cc: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Fri, 04 Feb 2000 13:06:42 EST." <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> Date: Fri, 04 Feb 2000 13:17:21 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > The point is, when you dial an international number, you the client in fact > know full well that there is a country code (at very least). no. you don't even know that. you just dial the international prefix followed by the digits that are on someone's business card. or, soon, you click on a tel: URL link and the dialing gets done for you. except for some knowledge of local prefix rules, users don't have to know the structure of phone numbers in order to use them. that's a feature, not a bug. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 13:27:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05643 for ; Fri, 4 Feb 2000 13:27:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08172 for ; Fri, 4 Feb 2000 13:25:40 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05638; Fri, 4 Feb 2000 13:27:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08114; Fri, 4 Feb 2000 13:25:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08087 for ; Fri, 4 Feb 2000 13:25:34 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05635; Fri, 4 Feb 2000 13:26:57 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayz25276; Fri, 4 Feb 2000 18:26:52 GMT Message-ID: <389B1A97.A494D861@dynamicsoft.com> Date: Fri, 04 Feb 2000 13:29:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Randy Bush'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4102273CEB77D211869200805FE6F59356EDD4@xch-phl-01.he.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Manfredi, Albert E" wrote: > > The point is, when you dial an international number, you the client in fact > know full well that there is a country code (at very least). So _that_ much > can be delimeted by a dot without undue hardship. All countries also use a > city/area code of some kind. It's not too much to ask to delimit that as > well. > > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. Wrong. The human user doesn't do this unless the UI on your phone/software is really bad. Most likely you'll enter the number, hit return, and the host will perform this translation. As Randy pointed out, its been going on for a while now... -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 13:35:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05890 for ; Fri, 4 Feb 2000 13:35:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08560 for ; Fri, 4 Feb 2000 13:33:35 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05885; Fri, 4 Feb 2000 13:35:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08505; Fri, 4 Feb 2000 13:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08480 for ; Fri, 4 Feb 2000 13:33:29 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05877; Fri, 4 Feb 2000 13:34:54 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id NAA04767; Fri, 4 Feb 2000 13:34:49 -0500 (EST) Date: Fri, 4 Feb 2000 13:34:49 -0500 (EST) From: Scott Bradner Message-Id: <200002041834.NAA04767@newdev.harvard.edu> To: Albert.Manfredi@PHL.Boeing.com, enum@ietf.org, itu+ietf@ietf.org, randy@psg.com Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > What I think is truly "unworkable" (a favorite word here) is the current > plan, which requires every normal human to write down the phone number on a > piece of paper before being able to type it in, in reverse order, with all > the dots. oh, here is the basic disconnect - the all-them-dots version is what is sent to the DNS it does not have to be what the user types (in fact it would be quite broken if the user had to type any of this) Scott _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 15:34:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09635 for ; Fri, 4 Feb 2000 15:34:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11667 for ; Fri, 4 Feb 2000 15:33:32 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09630; Fri, 4 Feb 2000 15:34:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11604; Fri, 4 Feb 2000 15:33:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11579 for ; Fri, 4 Feb 2000 15:33:25 -0500 (EST) Received: from relay.cwplc.com ([194.6.6.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09627; Fri, 4 Feb 2000 15:34:44 -0500 (EST) Received: from gb-cwc-wtn-msw4 ([148.185.175.64]) by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id UAA09792; Fri, 4 Feb 2000 20:34:39 GMT Received: from gb-cwc-wtn-i02.isops.mercury.co.uk (unverified) by gb-cwc-wtn-msw4 (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 04 Feb 2000 15:08:51 +0000 Received: by gb-cwc-wtn-io2.isops.cwcom.co.uk with Internet Mail Service (5.5.2650.21) id <12XKV91C>; Fri, 4 Feb 2000 14:58:48 -0000 Message-Id: <29B7C7A8E3E4D111ABDB0000F80864000318FE89@gbcwcbrtm003.isops.cwcom.co.uk> From: "Rosbotham, Paul" To: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 15:12:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [ITU+IETF] RE: [Enum] Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Alain, My understanding is that it was chosen to use dots between each individual digit in order that the client software does not need to have a detailed knowledge of E.164. For example, if you were to break the number below into administrative "domains", you would have 2804.6265.8.46.e164.int (I think), on the basis that; 46 is country code for Sweden 8 is area code for Stockholm 6265 identifies the exchange (Tele2 I guess) 2804 identifies the line on the exchange. However, to do this you'd need to know that 46 is a 2 digit country code, that area code 8 within Sweden is a 1 digit code etc, which would be far too onerous. On the other hand, if you dot each individual digit of the E.164 number, the client software won't need to know the E.164 structure, and the routeing to the correct server would be handled by DNS, eg the server for .164.int would know that .4.6.e164.int should be sent to a Swedish server, which in turn would know that .8.4.6.e164.int would be handled by a Stockholm server. Hope this clarifies (hope it's correct!) Paul > -----Original Message----- > From: alain.doisneau@art-telecom.fr [SMTP:alain.doisneau@art-telecom.fr] > Sent: Friday, February 04, 2000 1:37 PM > To: enum@ietf.org; itu+ietf@ietf.org > Cc: rshockey@ix.netcom.com > Subject: [Enum] Structure of DNS entry for ENUM > > Dear All, > > I attended the last ITU+IETF workshop (Geneva 25-27 Jan 2000) and I have > still a question regarding the presentation made by R. Shockey. > > It's about the linkage between E.164 resources and IP names (or addresses > here ?) > > He gave an example : > "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int" > I understand that "e164.int" might become a new global TLD, but what do > mean > the digits of the E.164 number as they are i.e separated by a dot and > therefore, I suppose, having to point out INDIVIDUALLY to certain IP > addresses. > In the example, the E.164 number is a number in Sweden, country whose > E.164 > country code is 46, therefore, "46" has a meaning (i.e. look at the > swedish > numbering plan, not to another one), but the digits "4" and "6" taken one > at > a time do not mean anything. > > Could somebody explain me this issue ? > > Thank you in advance > > Alain Doisneau : mailto alain.doisneau@art-telecom.fr > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 17:28:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11884 for ; Fri, 4 Feb 2000 17:28:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14627 for ; Fri, 4 Feb 2000 17:27:02 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11879; Fri, 4 Feb 2000 17:28:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14575; Fri, 4 Feb 2000 17:26:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14543 for ; Fri, 4 Feb 2000 17:26:55 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11876; Fri, 4 Feb 2000 17:28:17 -0500 (EST) Received: by dnspri.npac.com; id QAA07457; Fri, 4 Feb 2000 16:28:16 -0600 (CST) Received: from nodnsquery(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma007385; Fri, 4 Feb 00 16:27:41 -0600 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 16:23:19 -0600 Message-ID: From: Mark Foster To: "Rosen, Brian" , "'Manfredi, Albert E'" , "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 16:19:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org IMHO, it already has started to disintegrate at the country code level for certain countries. In a few weeks, the FCC is expected to release a number conservation order that will mandate number pooling in the US. This will mean that all new number block assignments to carriers will be made in smaller increments using LNP as the activation means, instead of by unique NPA-NXX level assignments in the LERG. This will dramatically increase the proportion of numbers routed via the LNP database over and above those simply resulting from service provider competition. While the actual zone delegation scheme is presumably out of ENUM scope, I certainly agree with the notion of isolating clients from the details of the structure, as it will certainly evolve. The default option is to make no delegation structure assumptions and always place a dot between every digit. R, Mark ------------------------------------------------------------- Mark D. Foster | EMAIL: mark.foster@neustar.com CTO | NeuStar, Inc. TEL: +1 202 533 2800/2702 | FAX: +1 202 533 2975 1120 Vermont Ave NW, Suite 550 | Washington, DC 20005 -----Original Message----- From: Rosen, Brian [mailto:brosen@fore.com] Sent: Friday, February 04, 2000 11:44 AM To: 'Manfredi, Albert E'; 'Randy Bush' Cc: enum@ietf.org; itu+ietf@ietf.org Subject: RE: [Enum] Re: Structure of DNS entry for ENUM This whole thing starts to fall apart when LNP is introduced. If the EU ever mandated LNP between countries, even that would break down. I guess the issue is: we know that the structure of E.164 is breaking down, we can only speculate how fast it disintegrates. We know that it eventually disintegrates into a data dip on the entire E.164, so should ENUM define something that works for some undefined interim time period or not? If we decide that it should optimize some level of structure, how deep should it go? It seems to me that it is NOT a good idea to have something between 2.1.2.1.5.5.5.2.1.2.1.e164.int and 12125551212.e164.int, because as the structure disintegrates, both mechanisms continue to work, but an intermediate one -- say 5551212.212.1.e164.int -- fails when cross area code LNP is mandated. The problem is that even if the DNS were reorganized, the CLIENTS would have to be reprogrammed, since they have to know to form the query as, say 2125551212.1.e164.int. Not a good plan IMO. Brian > -----Original Message----- > From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] > Sent: Friday, February 04, 2000 11:30 AM > To: 'Randy Bush' > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [Enum] Re: Structure of DNS entry for ENUM > > > Randy Bush [mailto:randy@psg.com] wrote: > > > > I understand that "e164.int" might become a new global TLD, > > but what do mean > > > the digits of the E.164 number as they are i.e separated by > > a dot and > > > therefore, I suppose, having to point out INDIVIDUALLY to > certain IP > > > addresses. > > > > it is the phone number reversed and the dots are added in a > > way that allows > > dns delegation at any level in that phone number. e.g. > > > > phone number is +1 206 780 0431 > > > > look up 1.3.4.0.0.8.7.6.0.2.1.e164.int > > > > this allows the dns 'owner' of > > > > 6.0.2.1.e164.int > > > > (+1 206 all of the seattle area) to delegate > > > > 0.8.7.6.0.2.1.e164.int > > > > to the server set which just handles +1 206 780, bainbridge island. > > > > this is so it distributes well and hence scales well. > > True, and the reverse order is used because, as Steven Lind > pointed out, the > hierarchy in the names is opposite that of the E.164 numbers (and also > opposite that of the IP addresses, I might add). > > However, it's not clear to me why the fields of the E.164 > number which are > clearly delineated, such as country code and city/area code, > could not at > least have been kept together, delimited by dots. The long > series of dots > seems a bit excessive? > > One might _also_ argue that as long as e164.int is used in > the DNS name > field, the convention for the stuff up front be in accordance > with E.164? > > I think it would be far clearer, and no tremendous problem, to show > > +1 206 780 0431 > > as 1.206.7800431.e164.int, > > and a euro-style number like > > 39 06 3295887 as > > 39.06.3295887.e164.int. > > I mean, the whole point of DNS names was that they be clear > to a human, yes? > > I still think, though, that using the DNS field for AESAs, > peer to the IP > address field, would be a useful feature in addition to this naming > convention. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 17:41:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12084 for ; Fri, 4 Feb 2000 17:41:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14998 for ; Fri, 4 Feb 2000 17:40:09 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12079; Fri, 4 Feb 2000 17:41:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14937; Fri, 4 Feb 2000 17:39:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14912 for ; Fri, 4 Feb 2000 17:39:41 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12071; Fri, 4 Feb 2000 17:41:03 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA03924; Fri, 4 Feb 2000 14:40:41 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA08536; Fri, 4 Feb 2000 14:41:04 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Fri, 4 Feb 2000 14:40:47 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 17:40:46 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EDD8@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Mark Foster'" Cc: enum@ietf.org, itu+ietf@ietf.org Date: Fri, 4 Feb 2000 17:40:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Mark Foster [mailto:mark.foster@neustar.com] wrote: > While the actual zone delegation scheme is presumably out of > ENUM scope, I > certainly agree with the notion of isolating clients from the > details of the > structure, as it will certainly evolve. The default option > is to make no > delegation structure assumptions and always place a dot > between every digit. But is this strictly true? I mean, is whatever evolution that's about to befall on us going to make individual country codes hierarchical among themselves, for example? I'm asking because I don't know. As things are now, a 4 most significant digit can indicate Sweden, the Czech Republic, or the UK. A 2 can indicate Morocco, Egypt, or Greenland(!?). A 3 can indicate France, the Netherlands, or Italy. So the question is, will the individual-digit hierarchy be meaningful or not in the future? I guess the general consensus is that it will be making more sense, rather than less sense than it already makes? A dot between digits requires each digit to be meaningful hierarchically, yes? Bert albert.e.manfredi@boeing.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 4 18:36:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12815 for ; Fri, 4 Feb 2000 18:36:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16721 for ; Fri, 4 Feb 2000 18:35:23 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12810; Fri, 4 Feb 2000 18:36:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16662; Fri, 4 Feb 2000 18:35:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16637 for ; Fri, 4 Feb 2000 18:35:15 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12807; Fri, 4 Feb 2000 18:36:38 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA18785; Fri, 4 Feb 2000 18:36:47 -0500 (EST) Message-Id: <200002042336.SAA18785@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Manfredi, Albert E" cc: "'Mark Foster'" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Fri, 04 Feb 2000 17:40:45 EST." <4102273CEB77D211869200805FE6F59356EDD8@xch-phl-01.he.boeing.com> Date: Fri, 04 Feb 2000 18:36:47 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > So the question is, will the individual-digit hierarchy be meaningful or not > in the future? yes. you will always be able to represent the E.164 delegation hierarchy using a DNS tree where each digit is a separate DNS label. this would not necessarily be the case for a DNS tree where there were some multiple digit labels. that's why the one-digit-per-label representation is preferred. the nice thing about doing it this way is that the structure of phone numbers is reflected in the DNS tree, and can change from time to time, rather than being embedded either in lookup software or in users' minds. so for an example, to look up +1 865 974 3126 1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root <<< DNS root returns "I have no answers for you, but domains ending in .e164.net can be looked up at any of the following servers..." (list of servers for lookup of top-level e.164 prefixes follows) (this assumes that the root server also serves .net, as is currently the case for at least some of the root servers) 2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .e164.net <<< that server returns "I have no answers for you, but domains ending in .1.e164.net can be looked up at any of the following servers..." (list of servers for north america follows) 3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .1.e164.net <<< that server returns "I have no answers for you, but domains ending in .5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for Knoxville area, Tennessee, US follows) 4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .5.6.8.1.e164.net <<< that server returns "I have no answers for you, but domains ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for the University of Tennessee, Knoxville campus, follows) 5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for 3.4.7.9.5.6.8.1.e164.net <<< that server returns "here are the records for 6.2.1.3.4.7.9.5.6.8.1.e164.net" note that a) the query is the same at every step b) it's not necessary to make a separate query for each digit - each server returns a referral for the longest DNS suffix matching the query. c) if the structure of e.164 delegation changes, this change can be reflected in DNS without any changes whatsoever to client code. for instance, another level of delegation could be added for the +1 865 974- prefix, or the e164.net servers could be taught to lookup north american numbering plan area codes under +1, and delegate each area code to to the appropriate country's DNS servers, or directly to servers for those area codes. the client code doesn't have to know or care how this is done. d) in practice, the results of the first two or three or four queries are likely to be in a local cache, thus most lookup will not require that many queries. _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 05:49:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01745 for ; Mon, 7 Feb 2000 05:49:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12800 for ; Mon, 7 Feb 2000 05:47:44 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01740; Mon, 7 Feb 2000 05:49:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12753; Mon, 7 Feb 2000 05:47:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12711 for ; Mon, 7 Feb 2000 05:47:26 -0500 (EST) Received: from xn1-gw (xn1-b.atlas.fr [194.51.9.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01737; Mon, 7 Feb 2000 05:48:50 -0500 (EST) From: alain.doisneau@art-telecom.fr X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:39 +0100 X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:39 +0100 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 7 Feb 2000 11:47:44 +0100 X400-Received: by /PRMD=art-telecom/ADMD=atlas/C=fr/; Relayed; Mon, 7 Feb 2000 11:50:34 +0100 Date: Mon, 7 Feb 2000 11:50:34 +0100 X400-Originator: alain.doisneau@art-telecom.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=art-telecom/ADMD=atlas/C=fr/;<003c01bf7159$29993e00$01046182>] Original-Encoded-Information-Types: teletex X400-Content-Type: P2-1988 (22) Content-Identifier: Re: -ITU+IETF... Message-ID: <003c01bf7159S29993e00S01040b8baadu*@MHS> To: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com Cc: mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA12712 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear All, As I launched this debate, i first of all thank you who had given your answers and comments. Among all of them, I appreciate the following for it thoroughly clarified the issue to me (with the exception of the .net suffix which looks strange - shouldn'it have been .int instead ?). Regards Alain Doisneau : alain.doisneau@art-telecom.fr -----Message d'origine----- De : moore@cs.utk.edu À : Albert.Manfredi@PHL.Boeing.com Cc : mark.foster@neustar.com ; enum@ietf.org ; itu+ietf@ietf.org Date : samedi 5 février 2000 01:48 Objet : Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM >> So the question is, will the individual-digit hierarchy be meaningful or not >> in the future? > >yes. you will always be able to represent the E.164 delegation hierarchy >using a DNS tree where each digit is a separate DNS label. this would >not necessarily be the case for a DNS tree where there were some >multiple digit labels. that's why the one-digit-per-label representation >is preferred. > >the nice thing about doing it this way is that the structure of phone >numbers is reflected in the DNS tree, and can change from time to time, >rather than being embedded either in lookup software or in users' minds. > >so for an example, to look up +1 865 974 3126 > >1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root > ><<< DNS root returns "I have no answers for you, but domains > ending in .e164.net can be looked up at any of the following servers..." > > (list of servers for lookup of top-level e.164 prefixes follows) > > (this assumes that the root server also serves .net, as is > currently the case for at least some of the root servers) > >2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .e164.net > ><<< that server returns "I have no answers for you, but domains > ending in .1.e164.net can be looked up at any of the following > servers..." > > (list of servers for north america follows) > >3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .1.e164.net > > ><<< that server returns "I have no answers for you, but domains > ending in .5.6.8.1.e164.net can be looked up at any of the > following servers..." > > (list of servers for Knoxville area, Tennessee, US follows) > >4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for .5.6.8.1.e164.net > ><<< that server returns "I have no answers for you, but domains > ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of > the following servers..." > > (list of servers for the University of Tennessee, Knoxville > campus, follows) > >5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the > DNS servers listed for 3.4.7.9.5.6.8.1.e164.net > ><<< that server returns "here are the records for > 6.2.1.3.4.7.9.5.6.8.1.e164.net" > >note that > >a) the query is the same at every step >b) it's not necessary to make a separate query for each digit - > each server returns a referral for the longest DNS suffix > matching the query. >c) if the structure of e.164 delegation changes, this change > can be reflected in DNS without any changes whatsoever > to client code. for instance, another level of delegation > could be added for the +1 865 974- prefix, or the e164.net > servers could be taught to lookup north american numbering > plan area codes under +1, and delegate each area code to > to the appropriate country's DNS servers, or directly to > servers for those area codes. the client code doesn't have > to know or care how this is done. >d) in practice, the results of the first two or three or four > queries are likely to be in a local cache, thus most lookup > will not require that many queries. > > >_______________________________________________ >ITU+IETF mailing list >ITU+IETF@ietf.org >http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 08:10:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05769 for ; Mon, 7 Feb 2000 08:10:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16144 for ; Mon, 7 Feb 2000 08:09:01 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05763; Mon, 7 Feb 2000 08:10:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16083; Mon, 7 Feb 2000 08:08:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16059 for ; Mon, 7 Feb 2000 08:08:42 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05720; Mon, 7 Feb 2000 08:10:07 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA19422; Mon, 7 Feb 2000 08:09:49 -0500 (EST) Message-Id: <200002071309.IAA19422@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alain.doisneau@art-telecom.fr cc: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com, mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 11:50:34 +0100." <003c01bf7159S29993e00S01040b8baadu*@MHS> Date: Mon, 07 Feb 2000 08:09:49 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > As I launched this debate, i first of all thank you who had given your > answers and comments. > Among all of them, I appreciate the following for it thoroughly clarified > the issue to me thanks for the compliment! > (with the exception of the .net suffix which looks strange - > shouldn'it have been .int instead ?). it could be either .int or .net and still work just as well. (assuming that nobody has bought e164.net by then!) I did not suggest .int because some people consider it controversial, and I didn't want a debate about .int to cloud the explanation of how DNS lookups of E.164 numbers would work. And I haven't been closely following the enum discussion, so I don't know what's been decided about this. But if the people who run .int have no objection to defining e164.int, then neither do I. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 08:37:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07660 for ; Mon, 7 Feb 2000 08:37:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16911 for ; Mon, 7 Feb 2000 08:36:16 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07653; Mon, 7 Feb 2000 08:37:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16855; Mon, 7 Feb 2000 08:36:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16830 for ; Mon, 7 Feb 2000 08:36:09 -0500 (EST) Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07644; Mon, 7 Feb 2000 08:37:35 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Feb 2000 14:38:23 +0100 Message-ID: From: "Shaw, Robert" To: "'Keith Moore'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 14:37:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 09:43:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11122 for ; Mon, 7 Feb 2000 09:43:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19048 for ; Mon, 7 Feb 2000 09:41:52 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11117; Mon, 7 Feb 2000 09:43:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18981; Mon, 7 Feb 2000 09:41:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18957 for ; Mon, 7 Feb 2000 09:41:31 -0500 (EST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11100; Mon, 7 Feb 2000 09:42:55 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Mon, 7 Feb 2000 09:41:53 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1NWN5JB6>; Mon, 7 Feb 2000 09:41:54 -0500 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919BD0@bcarua63.ca.nortel.com> From: "Anne Brown" To: "'Shaw, Robert'" , "'Keith Moore'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 09:41:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7179.7936D4A2" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org 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_01BF7179.7936D4A2 Content-Type: text/plain; charset="iso-8859-1" FYI. I believe Lucent established e164.org for enum development testing and would be willing to give it up to whomever it makes sense to do so. Regards, Anne -----Original Message----- From: Shaw, Robert [mailto:Robert.Shaw@itu.int] Sent: February 07, 2000 8:37 AM To: 'Keith Moore' Cc: enum@ietf.org; itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf ------_=_NextPart_001_01BF7179.7936D4A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for = ENUM

FYI.  I believe Lucent = established e164.org for enum development testing and would be willing = to give it up to whomever it makes sense to do so.

Regards,
Anne

      -----Original = Message-----
      From:   Shaw, Robert [mailto:Robert.Shaw@itu.int]
      Sent:   February 07, 2000 8:37 AM
      To:     'Keith Moore'
      Cc:     enum@ietf.org; itu+ietf@ietf.org
      Subject:       = RE: [ITU+IETF] RE: [Enum] Re: = Structure of DNS entry for ENUM

      > -----Original Message-----
      > From: Keith Moore [mailto:moore@cs.utk.edu]
      > Sent: Monday, February 07, 2000 = 2:10 PM
      > To: = alain.doisneau@art-telecom.fr
      > Cc: moore@cs.utk.edu; = Albert.Manfredi@PHL.Boeing.com;
      > mark.foster@neustar.com; = enum@ietf.org; itu+ietf@ietf.org
      > Subject: Re: [ITU+IETF] RE: = [Enum] Re: Structure of DNS entry
      > for ENUM
      >
      >
      > it could be either .int or .net = and still work just as well.
      > (assuming that nobody has bought = e164.net by then!)
      >

      hmmm...

      some folks called netnumber.com have = e164.com

      Peter Lothberg has e164.net

      Lucent has e164.org

      I wonder what would be the result of a = UDRP challenge
      to these names (I think I'm = joking...)

      Bob


      _______________________________________________
      ITU+IETF mailing list
      ITU+IETF@ietf.org
      http://www.ietf.org/mailman/listinfo/itu+ietf

------_=_NextPart_001_01BF7179.7936D4A2-- _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 09:50:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11333 for ; Mon, 7 Feb 2000 09:50:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19373 for ; Mon, 7 Feb 2000 09:49:25 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11328; Mon, 7 Feb 2000 09:50:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19291; Mon, 7 Feb 2000 09:48:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19266 for ; Mon, 7 Feb 2000 09:48:39 -0500 (EST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11303; Mon, 7 Feb 2000 09:50:02 -0500 (EST) Received: from laptop (stl-mo15-09.ix.netcom.com [207.222.133.137]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id JAA03396; Mon, 7 Feb 2000 09:49:28 -0500 (EST) Message-Id: <4.2.0.58.20000207083841.00b30ed0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 07 Feb 2000 08:48:39 -0600 To: Keith Moore , alain.doisneau@art-telecom.fr From: Richard Shockey Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Cc: moore@cs.utk.edu, Albert.Manfredi@PHL.Boeing.com, mark.foster@neustar.com, enum@ietf.org, itu+ietf@ietf.org In-Reply-To: <200002071309.IAA19422@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > >I did not suggest .int because some people consider it controversial, >and I didn't want a debate about .int to cloud the explanation of >how DNS lookups of E.164 numbers would work. And I haven't been >closely following the enum discussion, so I don't know what's been >decided about this. But if the people who run .int have no objection >to defining e164.int, then neither do I. > >Keith An realistically we can use any domain and TLD we can agree on.... [number].domain.foo. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 09:53:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11457 for ; Mon, 7 Feb 2000 09:53:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19546 for ; Mon, 7 Feb 2000 09:52:03 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11447; Mon, 7 Feb 2000 09:53:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19479; Mon, 7 Feb 2000 09:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19459 for ; Mon, 7 Feb 2000 09:51:47 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11425; Mon, 7 Feb 2000 09:53:06 -0500 (EST) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <1F227ZDM>; Mon, 7 Feb 2000 15:53:52 +0100 Message-ID: <98388C05D464D111B61800805F1504160123E51F@p-ibis.issy.cnet.fr> From: BARNOLE Valerie CNET/DAC/ISS To: "'Shaw, Robert'" , "'Keith Moore'" , "'Alain DOISNEAU'" Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 15:53:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA19460 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I do not know where is the right place to discuss about the e164.foo to choose, but the discussion will have to take place somewhere one of these days. From Bob Shaw's answer, it seems to me that the easy solution is to use e164.int, because I think that ITU, which has been allocated .int (I think so), is not using it by now. Am I right ? Politically, from a naive point of view, it should hurt nobody because ITU is already in charge of the international E.164 numbering plan (I do not omit the delegation to the different regulating authorities through the allocation of the geographical country codes). but maybe I am missing something ? As I have no real IP naming background or experience with IP names problems, I wonder if it is safe to use e164.foo if the domain e164 has already been bought by other entities under other GTLDs. Your comments are welcome. end of message _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Valérie Barnole FT.BD/CNET/DAC/ARS tel. : + 33 1 45 29 58 39 fax : + 33 1 46 29 31 42 valerie.barnole@cnet.francetelecom.fr -----Message d'origine----- De: Shaw, Robert [mailto:Robert.Shaw@itu.int] Date: lundi 7 février 2000 14:37 À: 'Keith Moore' Cc: enum@ietf.org; itu+ietf@ietf.org Objet: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 07, 2000 2:10 PM > To: alain.doisneau@art-telecom.fr > Cc: moore@cs.utk.edu; Albert.Manfredi@PHL.Boeing.com; > mark.foster@neustar.com; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > it could be either .int or .net and still work just as well. > (assuming that nobody has bought e164.net by then!) > hmmm... some folks called netnumber.com have e164.com Peter Lothberg has e164.net Lucent has e164.org I wonder what would be the result of a UDRP challenge to these names (I think I'm joking...) Bob _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 11:06:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13570 for ; Mon, 7 Feb 2000 11:06:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22327 for ; Mon, 7 Feb 2000 11:04:52 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13565; Mon, 7 Feb 2000 11:06:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22255; Mon, 7 Feb 2000 11:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22223 for ; Mon, 7 Feb 2000 11:04:35 -0500 (EST) Received: from roam.psg.com ([216.33.132.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13556; Mon, 7 Feb 2000 11:05:58 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Hqed-00012p-00; Mon, 07 Feb 2000 08:04:47 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Shockey Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <4.2.0.58.20000207083841.00b30ed0@127.0.0.1> Message-Id: Date: Mon, 07 Feb 2000 08:04:47 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > An realistically we can use any domain and TLD we can agree on.... > [number].domain.foo. actually, we don't have to agree. there can be consortia/conspiracies/ brokerages, each covering all or part of the global phone space and each using its own domain appendage. an outbound call would try to resolve in each of the consortia/domains in which it participates in order of preference. randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 11:16:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13862 for ; Mon, 7 Feb 2000 11:16:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22727 for ; Mon, 7 Feb 2000 11:14:46 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13857; Mon, 7 Feb 2000 11:16:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22656; Mon, 7 Feb 2000 11:14:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22634 for ; Mon, 7 Feb 2000 11:14:14 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13851; Mon, 7 Feb 2000 11:15:38 -0500 (EST) Received: by bastiont.npac.com; id LAA13595; Mon, 7 Feb 2000 11:15:39 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma013464; Mon, 7 Feb 00 11:14:48 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 10:10:24 -0600 Message-ID: From: James Yu To: "'Randy Bush'" Cc: Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 10:07:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org This means that the client would need to know which consortium/domain to use when sending the DNS query. It may be fine if the client only handles calls within a consortium/domain. But it won't be true for all the clients. James > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 07, 2000 11:05 AM > To: Richard Shockey > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > > An realistically we can use any domain and TLD we can agree on.... > > [number].domain.foo. > > actually, we don't have to agree. there can be > consortia/conspiracies/ > brokerages, each covering all or part of the global phone > space and each > using its own domain appendage. an outbound call would try > to resolve in > each of the consortia/domains in which it participates in order of > preference. > > randy > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:08:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15532 for ; Mon, 7 Feb 2000 12:08:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25134 for ; Mon, 7 Feb 2000 12:07:18 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15527; Mon, 7 Feb 2000 12:08:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25081; Mon, 7 Feb 2000 12:07:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25057 for ; Mon, 7 Feb 2000 12:07:11 -0500 (EST) Received: from wodc7mr3.ffx.ops.us.uu.net (wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15524; Mon, 7 Feb 2000 12:08:37 -0500 (EST) Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibjw06695; Mon, 7 Feb 2000 17:08:36 GMT Message-ID: <389EFCD2.71C1E55E@dynamicsoft.com> Date: Mon, 07 Feb 2000 12:11:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu CC: "'Randy Bush'" , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James Yu wrote: > > This means that the client would need to know which consortium/domain to use > when sending the DNS query. It may be fine if the client only handles calls > within a consortium/domain. But it won't be true for all the clients. I don't think we're trying to solve all aspects of the general problem here. I think our job is to start with a tld, and from there, figure out how to formulate the query to get back some kind of useful response. Deciding who owns these tld's, and how to configure them in clients, is important but not what we are solving here. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:28:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16090 for ; Mon, 7 Feb 2000 12:28:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25738 for ; Mon, 7 Feb 2000 12:27:07 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16085; Mon, 7 Feb 2000 12:28:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25677; Mon, 7 Feb 2000 12:27:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25654 for ; Mon, 7 Feb 2000 12:27:01 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16082; Mon, 7 Feb 2000 12:28:27 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA24226; Mon, 7 Feb 2000 09:28:23 -0800 (PST) From: Bill Manning Message-Id: <200002071728.JAA24226@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:28:23 -0800 (PST) Cc: rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 08:04:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % % > An realistically we can use any domain and TLD we can agree on.... % > [number].domain.foo. % % actually, we don't have to agree. there can be consortia/conspiracies/ % brokerages, each covering all or part of the global phone space and each % using its own domain appendage. an outbound call would try to resolve in % each of the consortia/domains in which it participates in order of % preference. % % randy hum, so this method works well for the IP space as well, yes? your consortia can anchor its IPv4 space in seattle.wa.us. and I can stick my address space in shockwave.com; e.g. 16.172.seattle.wa.us & 24.172.shockwave.com and all will be well? I find this hard to fathom. --bill _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:31:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16281 for ; Mon, 7 Feb 2000 12:31:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25918 for ; Mon, 7 Feb 2000 12:29:46 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16276; Mon, 7 Feb 2000 12:31:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25851; Mon, 7 Feb 2000 12:29:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25831 for ; Mon, 7 Feb 2000 12:29:38 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16222; Mon, 7 Feb 2000 12:31:01 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Hs0D-0001I0-00; Mon, 07 Feb 2000 09:31:09 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071728.JAA24226@boreas.isi.edu> Message-Id: Date: Mon, 07 Feb 2000 09:31:09 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I find this hard to fathom. i am not surprised randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:33:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16342 for ; Mon, 7 Feb 2000 12:33:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26158 for ; Mon, 7 Feb 2000 12:32:07 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16337; Mon, 7 Feb 2000 12:33:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26106; Mon, 7 Feb 2000 12:32:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26073 for ; Mon, 7 Feb 2000 12:32:00 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16333; Mon, 7 Feb 2000 12:33:25 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA24984; Mon, 7 Feb 2000 09:32:01 -0800 (PST) From: Bill Manning Message-Id: <200002071732.JAA24984@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:32:01 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 09:31:09 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % % > I find this hard to fathom. % % i am not surprised % % randy % You should be. -- --bill _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:41:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16578 for ; Mon, 7 Feb 2000 12:41:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26443 for ; Mon, 7 Feb 2000 12:39:51 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16573; Mon, 7 Feb 2000 12:41:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26380; Mon, 7 Feb 2000 12:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26356 for ; Mon, 7 Feb 2000 12:39:44 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16461; Mon, 7 Feb 2000 12:39:56 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA20580; Mon, 7 Feb 2000 12:36:06 -0500 (EST) Message-Id: <200002071736.MAA20580@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 08:04:47 PST." Date: Mon, 07 Feb 2000 12:36:06 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > > An realistically we can use any domain and TLD we can agree on.... > > [number].domain.foo. > > actually, we don't have to agree. there can be consortia/conspiracies/ > brokerages, each covering all or part of the global phone space and each > using its own domain appendage. an outbound call would try to resolve in > each of the consortia/domains in which it participates in order of > preference. certainly a possible outcome. not necessarily a favorable one. (some folks would disagree about this) but I've always regarded this as the biggest problem facing enum - will it be politically possible to map the e.164 number space onto a single federated database (like DNS) such that: a) the result is reasonably consistent with the real e.164 world, (and also consistent from one client to another), and b) the results returned from a lookup of a phone number are under control of the owner of that phone number (perhaps via a proxy) i.e. mostly a technical problem rather than a political one. but it does make sense to tackle the technical problem first. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:52:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17095 for ; Mon, 7 Feb 2000 12:52:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26833 for ; Mon, 7 Feb 2000 12:50:53 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17090; Mon, 7 Feb 2000 12:52:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26767; Mon, 7 Feb 2000 12:50:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26747 for ; Mon, 7 Feb 2000 12:50:44 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17082; Mon, 7 Feb 2000 12:52:08 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA20656; Mon, 7 Feb 2000 12:43:06 -0500 (EST) Message-Id: <200002071743.MAA20656@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Bill Manning , rshockey@ix.netcom.com (Richard Shockey), enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 09:31:09 PST." Date: Mon, 07 Feb 2000 12:43:06 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > > I find this hard to fathom. > > i am not surprised well, it would seem odd for IETF to insist on consistency of meaning for IP numbers (modulo private address space) but not care about consistency of meaning for E.164 numbers. seems like users' interests are best served by having a consistent meaning, everywhere, for both kinds of address. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:53:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17141 for ; Mon, 7 Feb 2000 12:53:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26972 for ; Mon, 7 Feb 2000 12:52:17 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17136; Mon, 7 Feb 2000 12:53:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26911; Mon, 7 Feb 2000 12:52:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26888 for ; Mon, 7 Feb 2000 12:52:10 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17133; Mon, 7 Feb 2000 12:53:37 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsLg-0001K7-00; Mon, 07 Feb 2000 09:53:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071743.MAA20656@astro.cs.utk.edu> Message-Id: Date: Mon, 07 Feb 2000 09:53:20 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > seems like users' interests are best served by having a consistent > meaning, everywhere, for both kinds of address. so that's why the internet phyical topology is a simple dag. wow. never thought of that. the meaning of a phone number or an ip address is the endpoint, not the routing, not the billing, not how i derive the path to the endpoint, not .... randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:57:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17239 for ; Mon, 7 Feb 2000 12:57:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27201 for ; Mon, 7 Feb 2000 12:55:47 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17234; Mon, 7 Feb 2000 12:57:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27133; Mon, 7 Feb 2000 12:55:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27114 for ; Mon, 7 Feb 2000 12:55:35 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17231; Mon, 7 Feb 2000 12:57:02 -0500 (EST) Received: by bastiont.npac.com; id MAA01380; Mon, 7 Feb 2000 12:57:02 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma001184; Mon, 7 Feb 00 12:56:22 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 11:51:58 -0600 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" Cc: "'Randy Bush'" , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 11:48:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org I agree. But I'm replying to Randy's message that each consortium/domain may use one TLD (or including the 2nd level domain) for its own use. That consortium/domain may only handle certain phone numbers, not all of them. We should be looking for a scheme that can cover the aspects we can think of. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, February 07, 2000 12:12 PM > To: James Yu > Cc: 'Randy Bush'; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > James Yu wrote: > > > > This means that the client would need to know which > consortium/domain to use > > when sending the DNS query. It may be fine if the client > only handles calls > > within a consortium/domain. But it won't be true for all > the clients. > > I don't think we're trying to solve all aspects of the general problem > here. I think our job is to start with a tld, and from there, > figure out > how to formulate the query to get back some kind of useful response. > Deciding who owns these tld's, and how to configure them in > clients, is > important but not what we are solving here. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:58:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17334 for ; Mon, 7 Feb 2000 12:58:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27341 for ; Mon, 7 Feb 2000 12:57:08 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17328; Mon, 7 Feb 2000 12:58:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27271; Mon, 7 Feb 2000 12:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27250 for ; Mon, 7 Feb 2000 12:56:59 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17315; Mon, 7 Feb 2000 12:58:25 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA28227; Mon, 7 Feb 2000 09:58:18 -0800 (PST) From: Bill Manning Message-Id: <200002071758.JAA28227@boreas.isi.edu> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM To: randy@psg.com (Randy Bush) Date: Mon, 7 Feb 2000 09:58:18 -0800 (PST) Cc: moore@cs.utk.edu (Keith Moore), enum@ietf.org, itu+ietf@ietf.org In-Reply-To: from "Randy Bush" at Feb 07, 2000 09:53:20 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % % > seems like users' interests are best served by having a consistent % > meaning, everywhere, for both kinds of address. % % so that's why the internet phyical topology is a simple dag. wow. never % thought of that. % % the meaning of a phone number or an ip address is the endpoint, not the % routing, not the billing, not how i derive the path to the endpoint, not % .... % % randy % then just use the e164 RR and go home, your job here is done. -- --bill _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 12:59:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17395 for ; Mon, 7 Feb 2000 12:59:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27453 for ; Mon, 7 Feb 2000 12:57:46 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17389; Mon, 7 Feb 2000 12:59:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27390; Mon, 7 Feb 2000 12:57:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27368 for ; Mon, 7 Feb 2000 12:57:37 -0500 (EST) Received: from bastiont.npac.com (firewall-user@bastiont.npac.com [208.143.34.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17377; Mon, 7 Feb 2000 12:59:03 -0500 (EST) Received: by bastiont.npac.com; id MAA02118; Mon, 7 Feb 2000 12:59:02 -0500 (EST) Received: from nodnsquery(208.143.39.132) by bastiont.npac.com via smap (V5.0) id xma001962; Mon, 7 Feb 00 12:58:37 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 11:54:13 -0600 Message-ID: From: James Yu To: "'Randy Bush'" Cc: enum@ietf.org, itu+ietf@ietf.org, Keith Moore Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 11:51:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Randy, Shouldn't those be handled by the NAPTRs/SRVs instead of TLDs? James > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 07, 2000 12:53 PM > To: Keith Moore > Cc: enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry > for ENUM > > > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > so that's why the internet phyical topology is a simple dag. > wow. never > thought of that. > > the meaning of a phone number or an ip address is the > endpoint, not the > routing, not the billing, not how i derive the path to the > endpoint, not > .... > > randy > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 13:01:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17561 for ; Mon, 7 Feb 2000 13:01:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27601 for ; Mon, 7 Feb 2000 12:59:58 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17556; Mon, 7 Feb 2000 13:01:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27540; Mon, 7 Feb 2000 12:59:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27510 for ; Mon, 7 Feb 2000 12:59:51 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17550; Mon, 7 Feb 2000 13:01:16 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA20955; Mon, 7 Feb 2000 13:00:47 -0500 (EST) Message-Id: <200002071800.NAA20955@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 09:53:20 PST." Date: Mon, 07 Feb 2000 13:00:47 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > so that's why the internet phyical topology is a simple dag. wow. never > thought of that. I think you're missing the point. > the meaning of a phone number or an ip address is the endpoint, not the > routing, not the billing, not how i derive the path to the endpoint, not > .... I agree, but you appear to be confusing the multipath routing problem with the database consistency problem. I have no problem in principle with having multiple ways to look up phone numbers as long as, in practice, the meanings are reasonably consistent and up-to-date. but I suspect that it's easier to figure out how to get multiple parties to share a single federation tree than to keep several mutually autonomous trees consistent with one another. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 13:04:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17726 for ; Mon, 7 Feb 2000 13:04:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27872 for ; Mon, 7 Feb 2000 13:03:22 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17721; Mon, 7 Feb 2000 13:04:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27812; Mon, 7 Feb 2000 13:03:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27792 for ; Mon, 7 Feb 2000 13:03:12 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17711; Mon, 7 Feb 2000 13:04:38 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsWf-0001LZ-00; Mon, 07 Feb 2000 10:04:41 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: James Yu Cc: enum@ietf.org, itu+ietf@ietf.org, Keith Moore Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: Message-Id: Date: Mon, 07 Feb 2000 10:04:41 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Shouldn't those be handled by the NAPTRs/SRVs instead of TLDs? different tlds allow non-interaction/coordination between consortia. and these are really the same service using different provicers. randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 13:08:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17824 for ; Mon, 7 Feb 2000 13:08:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28078 for ; Mon, 7 Feb 2000 13:06:44 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17819; Mon, 7 Feb 2000 13:08:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28021; Mon, 7 Feb 2000 13:06:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27998 for ; Mon, 7 Feb 2000 13:06:37 -0500 (EST) Received: from roam.psg.com (t75.nanog.exodus.net [216.33.132.75] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17816; Mon, 7 Feb 2000 13:08:02 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HsZd-0001Lf-00; Mon, 07 Feb 2000 10:07:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Keith Moore Cc: enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM References: <200002071800.NAA20955@astro.cs.utk.edu> Message-Id: Date: Mon, 07 Feb 2000 10:07:45 -0800 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have no problem in principle with having multiple ways to look up > phone numbers as long as, in practice, the meanings are reasonably > consistent and up-to-date. 411? 611? i.e. for varying values of consistent. and that's the point. [ spoil your lunch and think of the interaction of this with dname, but it may help your consistency desires ] randy _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 13:19:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18090 for ; Mon, 7 Feb 2000 13:19:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28480 for ; Mon, 7 Feb 2000 13:17:35 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18085; Mon, 7 Feb 2000 13:19:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28449; Mon, 7 Feb 2000 13:17:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28273 for ; Mon, 7 Feb 2000 13:14:29 -0500 (EST) Received: from mandarin.com (mail.mandarin.com [212.212.92.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17999; Mon, 7 Feb 2000 13:15:53 -0500 (EST) Received: from mandarin.com ([127.0.0.1]) by mandarin.com with SMTP (NetNow!/3.0.0.999) id MNDR75300445; Mon, 07 Feb 2000 18:13:55 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Feb 2000 18:13 +0000 (GMT Standard Time) From: Management@numbering.com (Richard D G Cox) To: enum@ietf.org In-Reply-To: <200002071511.KAA20311@optimus.ietf.org> Reply-To: Management@numbering.com Message-Id: X-Hops: 1 Subject: [ITU+IETF] Re: Structure of DNS entry for ENUM Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Richard Shockey wrote: > realistically we can use any domain and TLD we can agree on.... Indeed. Using e164 is something of a hostage to fortune; it's not _that_ long since the standard was E.163 rather than E.164! At any time ITU-T could propose a new set of standards and a new E. number to go with them. Perhaps - given the significance of this - we should consider whether a separate (virtual) country-TLD is called for here? Of course, there's nothing to stop us continuing to use the e164.int as a placeholder in our discussions in ENUM! Anne Brown replied to : >> Please clarify "the owner of the telephone number" in Section 3.11. >> Is it the subscriber that is assigned the telephone number or the >> service provider that currently serves that number? > Section 3.11 on Privacy states that "The system MUST allow the owner > of the telephone number to control the information which prospective > callers may receive." I recommend replacing the text with "The system > MUST allow the user to whom the telephone number was assigned, the > ability to control the information...". This potato is hotter than you might have realised: we haven't yet defined the "user" (of the telephone network services) with sufficient clarity to avoid the sort of dispute that some of us are expecting/dreading. I don't have an answer to offer that I'm happy with, but give thought to the sort of situation where a paging bureau, message bureau, fax-to-email service etc. set up facilities and then offer them to downstream users. The bureau (or service provider) may not (depending on the country) be subject to the mandatory number portability requirement, but will normally have been assigned a block of telephone numbers (usually delivered using DNIS/DDI over a T1 or an E1) which they then sub-allocate to users. Which is to be the "user" for the purposes of Section 3.11? It's possible to make an arbitrary decision based on any one specific circumstance, but far harder to define an algorithmic rule that scales up or down to fit all the circumstances we are likely to come across! Richard Cox Mandarin Technology, Penarth, UK +44 (29) 2031 1131 _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 13:27:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18201 for ; Mon, 7 Feb 2000 13:27:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28766 for ; Mon, 7 Feb 2000 13:25:45 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18196; Mon, 7 Feb 2000 13:27:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28694; Mon, 7 Feb 2000 13:25:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28675 for ; Mon, 7 Feb 2000 13:25:38 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18184; Mon, 7 Feb 2000 13:27:05 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA21129; Mon, 7 Feb 2000 13:26:57 -0500 (EST) Message-Id: <200002071826.NAA21129@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 10:07:45 PST." Date: Mon, 07 Feb 2000 13:26:57 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > > I have no problem in principle with having multiple ways to look up > > phone numbers as long as, in practice, the meanings are reasonably > > consistent and up-to-date. > > 411? 611? i.e. for varying values of consistent. and that's the point. these are not e164 numbers. perhaps it's a good idea to handle these things, but that is not a compelling argument for multiple lookup services for e164 space. in general I would consider such things to be more akin to prefix handling (i.e. how do you map local dialling conventions onto real phone numbers) than to phone number lookup. Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 14:31:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19731 for ; Mon, 7 Feb 2000 14:31:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00928 for ; Mon, 7 Feb 2000 14:29:53 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19726; Mon, 7 Feb 2000 14:31:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00838; Mon, 7 Feb 2000 14:28:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00816 for ; Mon, 7 Feb 2000 14:28:34 -0500 (EST) Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19654; Mon, 7 Feb 2000 14:29:57 -0500 (EST) Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id LAA17735; Mon, 7 Feb 2000 11:28:20 -0800 (PST) From: "David Oran" To: "Keith Moore" , "Randy Bush" Cc: "Bill Manning" , "Richard Shockey" , , Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 14:28:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200002071743.MAA20656@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Perhaps because some people want to use enum for resolving telephone numbers other than e.164 globally-unique numbers, such as: 800 numbers (really names) 700 numbers (really names) private numbering plans I agree that if something is really truly a globally unique E.164 number there should be ony and only one root for resolving them. Unfortunately, you can't look at a string of digits and know that, unlike an IP address. > -----Original Message----- > From: itu+ietf-admin@ietf.org [mailto:itu+ietf-admin@ietf.org]On Behalf > Of Keith Moore > Sent: Monday, February 07, 2000 12:43 PM > To: Randy Bush > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > I find this hard to fathom. > > > > i am not surprised > > well, it would seem odd for IETF to insist on consistency of > meaning for IP numbers (modulo private address space) but not > care about consistency of meaning for E.164 numbers. > > seems like users' interests are best served by having a consistent > meaning, everywhere, for both kinds of address. > > Keith > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf > > _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 14:34:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19926 for ; Mon, 7 Feb 2000 14:34:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01196 for ; Mon, 7 Feb 2000 14:33:13 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19921; Mon, 7 Feb 2000 14:34:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01129; Mon, 7 Feb 2000 14:33:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01104 for ; Mon, 7 Feb 2000 14:32:59 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19917; Mon, 7 Feb 2000 14:34:25 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA21355; Mon, 7 Feb 2000 14:33:07 -0500 (EST) Message-Id: <200002071933.OAA21355@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "David Oran" cc: "Keith Moore" , "Randy Bush" , "Bill Manning" , "Richard Shockey" , enum@ietf.org, itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM In-reply-to: Your message of "Mon, 07 Feb 2000 14:28:20 EST." Date: Mon, 07 Feb 2000 14:33:06 -0500 Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > Perhaps because some people want to use enum for resolving telephone numbers > other than e.164 globally-unique numbers, such as: > 800 numbers (really names) > 700 numbers (really names) > private numbering plans > > I agree that if something is really truly a globally unique E.164 number > there should be ony and only one root for resolving them. Unfortunately, you > can't look at a string of digits and know that, unlike an IP address. and I agree that local/regional dialing conventions have to be supported. but I was assuming that they would be supported by some mechanism other than the DNS tree used for global E.164 numbers. And while you can probably use DNS tricks to handle a lot of local dialing conventions, it's not clear that you want to standardize on that approach. (how do you do intermediate dial tones, for instance?) Keith _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 14:37:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19980 for ; Mon, 7 Feb 2000 14:37:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01357 for ; Mon, 7 Feb 2000 14:36:05 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19975; Mon, 7 Feb 2000 14:37:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01309; Mon, 7 Feb 2000 14:35:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01277 for ; Mon, 7 Feb 2000 14:35:53 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19972; Mon, 7 Feb 2000 14:37:17 -0500 (EST) From: Melinda.Shore@nokia.com Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA19916; Mon, 7 Feb 2000 21:37:13 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id VAA16044; Mon, 7 Feb 2000 21:37:12 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Feb 2000 13:36:39 -0600 Message-ID: To: randy@psg.com Cc: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 13:36:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org > the meaning of a phone number or an ip address is the > endpoint, not the routing, not the billing, not how i > derive the path to the endpoint, not .... Alas, it's just not that simple anymore, especially when you take things like NAT into account. An E.164 address represents an endpoint (or user), but it unfortunately cannot reliably represent an IP address. There's a great big disconnect there, but fortunately if we accept the notion that the E.164 address is mapping to something else (like an H.323 gatekeeper), it gives us a leg up on the NAT problem. Melinda -- Melinda Shore Nokia IP Telephony 127 West State Street "Software longa, Ithaca, NY 14850 hardware brevis" +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore@nokia.com _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 15:20:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20792 for ; Mon, 7 Feb 2000 15:20:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02953 for ; Mon, 7 Feb 2000 15:18:50 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20787; Mon, 7 Feb 2000 15:20:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02864; Mon, 7 Feb 2000 15:18:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02816 for ; Mon, 7 Feb 2000 15:18:35 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20778; Mon, 7 Feb 2000 15:19:47 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA22227; Mon, 7 Feb 2000 15:19:13 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA22001; Mon, 7 Feb 2000 15:18:36 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2448.0) id <1H1F0VWH>; Mon, 7 Feb 2000 15:19:10 -0500 Message-ID: From: "Lind, Steven D, ALARC" To: "'David Oran'" , Keith Moore , Randy Bush Cc: Bill Manning , Richard Shockey , enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Mon, 7 Feb 2000 15:19:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Perhaps because some people want to use enum for resolving telephone numbers other than e.164 globally-unique numbers, such as: 800 numbers (really names) 700 numbers (really names) private numbering plans 800 and 700 numbers are E.164 numbers. Fully qualified, they would be +1 800 xxx xxxx or +1 700 xxx xxxx. Other countries have similar free phone services with their own set of E.164 numbers. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 --------------------------------------------------------------- > -----Original Message----- > From: David Oran [SMTP:oran@cisco.com] > Sent: Monday, February 07, 2000 2:28 PM > To: Keith Moore; Randy Bush > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for > ENUM > > Perhaps because some people want to use enum for resolving telephone > numbers > other than e.164 globally-unique numbers, such as: > 800 numbers (really names) > 700 numbers (really names) > private numbering plans > > I agree that if something is really truly a globally unique E.164 number > there should be ony and only one root for resolving them. Unfortunately, > you > can't look at a string of digits and know that, unlike an IP address. > > > -----Original Message----- > > From: itu+ietf-admin@ietf.org [mailto:itu+ietf-admin@ietf.org]On Behalf > > Of Keith Moore > > Sent: Monday, February 07, 2000 12:43 PM > > To: Randy Bush > > Cc: Bill Manning; Richard Shockey; enum@ietf.org; itu+ietf@ietf.org > > Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > > > > > > > > I find this hard to fathom. > > > > > > i am not surprised > > > > well, it would seem odd for IETF to insist on consistency of > > meaning for IP numbers (modulo private address space) but not > > care about consistency of meaning for E.164 numbers. > > > > seems like users' interests are best served by having a consistent > > meaning, everywhere, for both kinds of address. > > > > Keith > > > > _______________________________________________ > > ITU+IETF mailing list > > ITU+IETF@ietf.org > > http://www.ietf.org/mailman/listinfo/itu+ietf > > > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Mon Feb 7 17:55:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23699 for ; Mon, 7 Feb 2000 17:55:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07402 for ; Mon, 7 Feb 2000 17:54:03 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23694; Mon, 7 Feb 2000 17:55:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07363; Mon, 7 Feb 2000 17:53:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07344 for ; Mon, 7 Feb 2000 17:53:33 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23687 for ; Mon, 7 Feb 2000 17:54:57 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA12648; Mon, 7 Feb 2000 15:13:51 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id OAA25590; Mon, 7 Feb 2000 14:57:32 -0800 Message-Id: <4.1.20000207144342.01b416d0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Feb 2000 14:46:19 -0800 To: Andrew.Gallant@comsat.com From: Fred Baker Cc: "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , itu+ietf@ietf.org, Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" In-Reply-To: <00007843.C22219@comsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ITU+IETF] Re[2]: Key Exchange for Network Architectures (KENA) Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org At 09:03 AM 2/4/00 -0500, Andrew.Gallant@comsat.com wrote: > Sorry, folks. I only joined the list a few days ago, and think I > missed the beginning of this thread. OK, let me give you the executive summary. I sent notes to various RFC and Internet Draft authors, anyone who used the Acronym "IMSI" or referenced E.212/E.214 in their documents, saying "is this the IMSI that the ITU likes to talk about?" I got a resounding "yes, oops, I guess we missed including the reference". One hopes that the result will be, at minimum, the inclusion of the reference. The authors of this draft specifically would like to know what the concern is. _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 12:35:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03754 for ; Tue, 8 Feb 2000 12:35:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19007 for ; Tue, 8 Feb 2000 12:33:48 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03744; Tue, 8 Feb 2000 12:35:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18942; Tue, 8 Feb 2000 12:33:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18923 for ; Tue, 8 Feb 2000 12:33:33 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03724; Tue, 8 Feb 2000 12:35:01 -0500 (EST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 8 Feb 2000 11:33:41 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1QNDPBNZ>; Tue, 8 Feb 2000 11:33:38 -0600 Message-ID: <31AF4D00A662D211B6D10000F8BCBC24919BD3@bcarua63.ca.nortel.com> From: "Anne Brown" To: enum@ietf.org, itu+ietf@ietf.org Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM Date: Tue, 8 Feb 2000 11:33:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF725A.A10CC9FA" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org 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_01BF725A.A10CC9FA Content-Type: text/plain; charset="iso-8859-1" For clarification on the reasoning for the single-digit separation of E.164 digits for lookup purposes: This strategy was conceived in September 1996 with the following goals in mind: 1. Implementable by both DNS and LDAP and other repositories (at the same time, with partitioning depending on service and application requirements) 2. Allows lookups -vs- searching (both DNS and LDAP). A record or entry can be pin-pointed without white-pages type searching. 3. Supports distribution of E.164 resolution data by both blocks of numbers and by individual numbers. The strategy allows this distribution to be changed, when required, to reflect current realities. 4. Alleviates clients from having to know or be able to derive numbering plan structures and lengths (What a user types or dials is out of the problem scope) 5. Isolation from changes to numbering plan structures and lengths 6. Supports use of extensions, if required Regards, Anne -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: February 04, 2000 6:37 PM To: Manfredi, Albert E Cc: 'Mark Foster'; enum@ietf.org; itu+ietf@ietf.org Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM > So the question is, will the individual-digit hierarchy be meaningful or not > in the future? yes. you will always be able to represent the E.164 delegation hierarchy using a DNS tree where each digit is a separate DNS label. this would not necessarily be the case for a DNS tree where there were some multiple digit labels. that's why the one-digit-per-label representation is preferred. the nice thing about doing it this way is that the structure of phone numbers is reflected in the DNS tree, and can change from time to time, rather than being embedded either in lookup software or in users' minds. so for an example, to look up +1 865 974 3126 1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root <<< DNS root returns "I have no answers for you, but domains ending in .e164.net can be looked up at any of the following servers..." (list of servers for lookup of top-level e.164 prefixes follows) (this assumes that the root server also serves .net, as is currently the case for at least some of the root servers) 2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .e164.net <<< that server returns "I have no answers for you, but domains ending in .1.e164.net can be looked up at any of the following servers..." (list of servers for north america follows) 3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .1.e164.net <<< that server returns "I have no answers for you, but domains ending in .5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for Knoxville area, Tennessee, US follows) 4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for .5.6.8.1.e164.net <<< that server returns "I have no answers for you, but domains ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of the following servers..." (list of servers for the University of Tennessee, Knoxville campus, follows) 5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the DNS servers listed for 3.4.7.9.5.6.8.1.e164.net <<< that server returns "here are the records for 6.2.1.3.4.7.9.5.6.8.1.e164.net" note that a) the query is the same at every step b) it's not necessary to make a separate query for each digit - each server returns a referral for the longest DNS suffix matching the query. c) if the structure of e.164 delegation changes, this change can be reflected in DNS without any changes whatsoever to client code. for instance, another level of delegation could be added for the +1 865 974- prefix, or the e164.net servers could be taught to lookup north american numbering plan area codes under +1, and delegate each area code to to the appropriate country's DNS servers, or directly to servers for those area codes. the client code doesn't have to know or care how this is done. d) in practice, the results of the first two or three or four queries are likely to be in a local cache, thus most lookup will not require that many queries. _______________________________________________ enum mailing list enum@ietf.org http://www.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01BF725A.A10CC9FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for = ENUM

For clarification on the reasoning for = the single-digit separation of E.164 digits for lookup purposes:

This strategy was conceived in = September 1996 with the following goals in mind:

  1. Implementable by both = DNS and LDAP and other repositories (at the same time, with = partitioning depending on service and application = requirements)
  2. Allows lookups -vs- searching (both = DNS and LDAP).  A record or entry can be pin-pointed without = white-pages type searching.
  3. Supports distribution of E.164 = resolution data by both blocks of numbers and by individual = numbers.  The strategy allows this distribution to be changed, = when required, to reflect current realities.
  4. Alleviates clients from having to = know or be able to derive numbering plan structures and lengths (What a = user types or dials is out of the problem scope)   =
  5. Isolation from changes to numbering = plan structures and lengths
  6. Supports use of extensions, if = required

Regards,
Anne


      -----Original = Message-----
      From:   Keith Moore [mailto:moore@cs.utk.edu]=
      Sent:   February 04, 2000 6:37 PM
      To:     Manfredi, Albert E
      Cc:     'Mark Foster'; enum@ietf.org; itu+ietf@ietf.org
      Subject:       = Re: [ITU+IETF] RE: [Enum] Re: = Structure of DNS entry for ENUM

      > So the question is, will the = individual-digit hierarchy be meaningful or not
      > in the future?

      yes.  you will always be able to = represent the E.164 delegation hierarchy
      using a DNS tree where each digit is = a separate DNS label.   this would
      not necessarily be the case for a DNS = tree where there were some
      multiple digit labels.  that's = why the one-digit-per-label representation
      is preferred.

      the nice thing about doing it this way = is that the structure of phone
      numbers is reflected in the DNS tree, = and can change from time to time,
      rather than being embedded either in = lookup software or in users' minds.

      so for an example, to look up +1 865 = 974 3126

      1. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root

      <<< DNS root returns "I = have no answers for you, but domains
          ending in = .e164.net can be looked up at any of the following = servers..."

          (list of servers = for lookup of top-level e.164 prefixes follows)

          (this assumes that = the root server also serves .net, as is
           currently = the case for at least some of the root servers)

      2. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .e164.net

      <<< that server returns = "I have no answers for you, but domains
          ending in = .1.e164.net can be looked up at any of the following
          = servers..."

          (list of servers = for north america follows)

      3. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .1.e164.net


      <<< that server returns = "I have no answers for you, but domains
          ending in = .5.6.8.1.e164.net can be looked up at any of the
          following = servers..."

          (list of servers = for Knoxville area, Tennessee, US follows)

      4. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = .5.6.8.1.e164.net

      <<< that server returns = "I have no answers for you, but domains
          ending in = 3.4.7.9.5.6.8.1.e164.net can be looked up at any of
          the following = servers..."

          (list of servers = for the University of Tennessee, Knoxville
           campus, = follows)

      5. send a query for = 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
         DNS servers listed for = 3.4.7.9.5.6.8.1.e164.net

      <<< that server returns = "here are the records for
          = 6.2.1.3.4.7.9.5.6.8.1.e164.net"

      note that

      a) the query is the same at every = step
      b) it's not necessary to make a = separate query for each digit -
         each server returns a = referral for the longest DNS suffix
         matching the = query.
      c) if the structure of e.164 = delegation changes, this change
         can be reflected in DNS = without any changes whatsoever
         to client = code.    for instance, another level of = delegation
         could be added for the = +1 865 974- prefix, or the e164.net
         servers could be taught = to lookup north american numbering
         plan area codes under = +1, and delegate each area code to
         to the appropriate = country's DNS servers, or directly to
         servers for those area = codes.  the client code doesn't have
         to know or care how this = is done.
      d) in practice, the results of the = first two or three or four
         queries are likely to be = in a local cache, thus most lookup
         will not require that = many queries.
       

      _______________________________________________
      enum mailing list
      enum@ietf.org
      http://www.ietf.org/mailman/listinfo/enum

------_=_NextPart_001_01BF725A.A10CC9FA-- _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 14:48:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09304 for ; Tue, 8 Feb 2000 14:48:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24996 for ; Tue, 8 Feb 2000 14:46:40 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09297; Tue, 8 Feb 2000 14:48:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24973; Tue, 8 Feb 2000 14:46:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24953 for ; Tue, 8 Feb 2000 14:46:28 -0500 (EST) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09294 for ; Tue, 8 Feb 2000 14:47:58 -0500 (EST) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 8 Feb 2000 14:47:09 -0500 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0000A3F3; Tue, 8 Feb 2000 14:47:36 -0800 Mime-Version: 1.0 Date: Tue, 8 Feb 2000 14:47:21 -0800 Message-ID: <0000A3F3.C22277@comsat.com> To: itu+ietf@ietf.org Cc: "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" , Fred Baker Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - long Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a set of comments on Workshop Issue 7 (E.212 IMSIs ...), and consists of: - description, - search results, - information on E.212, and - other comments. 1. From the Workshop Report, the description of Issue 7 is: - Issue #: 7 - Issue Title: E.212 - IMSIs & mobility with IP - Issue Description: In IETF documents, IMSI's are mentioned but ITU-T Rec E.212 is not often referenced. A review of the IETF documents is needed to ensure that the appropriate use of the term IMSI is used. - Related Work: Rec. E.212 Rec. E.214 3GPP 3GPP2 - Responsible Forum: IETF 2. Internet Drafts and RFCs were searched for mentions of E.212 and IMSIs. The search results were: - For E.212: 2 Internet Drafts 0 RFCs - For IMSI: 6 Internet Drafts 1 RFC (current The Internet Drafts mentioning E.212 were: - SS7 over internet applicability statement (draft-coene-ss7-over-ip-00.txt) and - Internet and SS7 addressing (draft-coene-ss7-IP-addr-00.txt). The Internet Drafts mentioning IMSI were: - Transparent Hierarchical Mobility Agents (THEMA) (draft-mccann-thema-00.txt) - Support of IPv6 over Cellular Communications Systems (6Tel) (draft-afifi-sixtel-00.txt) - IP Mobility Architecture Framework (draft-ietf-mobileip-ipm-arch-00.txt) - IP Mobility Architecture Framework (draft-becker-mobileip-ipm-arch-00.txt) - Key Exchange for Network Architectures (KENA) (draft-mkhalil-mobileip-kena-00.txt) - Mobile PPP (MPPP) (draft-ietf-pppext-mppp-01.txt) The RFC mentioning IMSI was: Wireless Device Configuration (OTASP/OTAPA) via ACAP (RFC2636). 3. Recommendation E.212 was revised by ITU-T Study Group 2 in 1998. The title is "THE INTERNATIONAL IDENTIFICATION PLAN FOR MOBILE TERMINALS AND MOBILE USERS." The revision reflects the more general scope of the term IMSI ("international mobile subscriber identity" -- formerly known as the "international mobile station identity") and what IMSIs could be used for. The "Table of Contents and Summary of Recommendation E.212 (11/98)" may be found at "http://www.itu.int/itudoc/itu-t/rec/e/s_e212.html". The summary is": "A plan for unique international identification of mobile terminals and mobile users is required in order to enable these terminals and users to roam among public networks which offer mobility services. International Mobile Subscriber Identity (IMSI) is required so that a visited network can identify a roaming mobile terminal or mobile user, e.g. in order to query a subscriber's home network for subscription and billing information. "Recommendation E.190 describes the general principles to be utilized in the assignment of ITU-T E-series international numbering resources. The procedures in this Recommendation, E.212, were developed in accordance with the principles contained in Recommendation E.190, and the statements contained in Recommendation E.190 take precedence over Recommendation E.212." The scope of E.212 is: "This Recommendation describes an international identification plan for mobile terminals or mobile users of public networks enabling roaming capabilities. It also establishes procedures for the assignment of International Mobile Subscriber Identities (IMSIs) to the mobile terminals and mobile users of such networks. This Recommendation describes the format of the IMSI." It is also noted there that: "an IMSI could be used to identify a UPT user or a subscriber to mobility services, as well as to identify a mobile terminal." A reference to E.212 from the ITU web site is: "[E.212] Recommendation E.212 (11/98) - The international identification plan for mobile terminals and mobile users." 4. Other comments: a. As Fred Baker said in an email, "... fundamentally, I think the ITU folks wanted to make sure that IETF use of "IMSI" and theirs correspond ...". I agree. b. The revisions to E.212 may be of interest to the IETF. c. I am not aware of any other Workshop-related issues for E.212 except for referencing the current version of the document. d. I am not aware of issues relevant to E.214, at least in ITU-T SG2, and there's not been any recent work on it there. Perhaps whoever suggested adding E.214 to the Related Work section of the Workshop matrix could identify if there are any issues that do fall within the Workshop's focus on Numbering, Naming, Addressing, and Routing. -Andy Gallant _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 14:48:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09321 for ; Tue, 8 Feb 2000 14:48:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25050 for ; Tue, 8 Feb 2000 14:46:48 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09316; Tue, 8 Feb 2000 14:48:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25025; Tue, 8 Feb 2000 14:46:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25006 for ; Tue, 8 Feb 2000 14:46:41 -0500 (EST) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09302 for ; Tue, 8 Feb 2000 14:48:10 -0500 (EST) From: Andrew.Gallant@comsat.com Received: from cqgate6.cmc.comsat.com ([134.133.162.21]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 8 Feb 2000 14:47:09 -0500 Received: from ccMail by cqgate6.cmc.comsat.com (IMA Internet Exchange 3.13) id 0000A267; Tue, 8 Feb 2000 14:51:45 -0500 Mime-Version: 1.0 Date: Tue, 8 Feb 2000 14:47:21 -0500 Message-ID: <0000A267.C22219@comsat.com> To: itu+ietf@ietf.org Cc: "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" , Fred Baker Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - long Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a set of comments on Workshop Issue 7 (E.212 IMSIs ...), and consists of: - description, - search results, - information on E.212, and - other comments. 1. From the Workshop Report, the description of Issue 7 is: - Issue #: 7 - Issue Title: E.212 - IMSIs & mobility with IP - Issue Description: In IETF documents, IMSI's are mentioned but ITU-T Rec E.212 is not often referenced. A review of the IETF documents is needed to ensure that the appropriate use of the term IMSI is used. - Related Work: Rec. E.212 Rec. E.214 3GPP 3GPP2 - Responsible Forum: IETF 2. Internet Drafts and RFCs were searched for mentions of E.212 and IMSIs. The search results were: - For E.212: 2 Internet Drafts 0 RFCs - For IMSI: 6 Internet Drafts 1 RFC (current The Internet Drafts mentioning E.212 were: - SS7 over internet applicability statement (draft-coene-ss7-over-ip-00.txt) and - Internet and SS7 addressing (draft-coene-ss7-IP-addr-00.txt). The Internet Drafts mentioning IMSI were: - Transparent Hierarchical Mobility Agents (THEMA) (draft-mccann-thema-00.txt) - Support of IPv6 over Cellular Communications Systems (6Tel) (draft-afifi-sixtel-00.txt) - IP Mobility Architecture Framework (draft-ietf-mobileip-ipm-arch-00.txt) - IP Mobility Architecture Framework (draft-becker-mobileip-ipm-arch-00.txt) - Key Exchange for Network Architectures (KENA) (draft-mkhalil-mobileip-kena-00.txt) - Mobile PPP (MPPP) (draft-ietf-pppext-mppp-01.txt) The RFC mentioning IMSI was: Wireless Device Configuration (OTASP/OTAPA) via ACAP (RFC2636). 3. Recommendation E.212 was revised by ITU-T Study Group 2 in 1998. The title is "THE INTERNATIONAL IDENTIFICATION PLAN FOR MOBILE TERMINALS AND MOBILE USERS." The revision reflects the more general scope of the term IMSI ("international mobile subscriber identity" -- formerly known as the "international mobile station identity") and what IMSIs could be used for. The "Table of Contents and Summary of Recommendation E.212 (11/98)" may be found at "http://www.itu.int/itudoc/itu-t/rec/e/s_e212.html". The summary is": "A plan for unique international identification of mobile terminals and mobile users is required in order to enable these terminals and users to roam among public networks which offer mobility services. International Mobile Subscriber Identity (IMSI) is required so that a visited network can identify a roaming mobile terminal or mobile user, e.g. in order to query a subscriber's home network for subscription and billing information. "Recommendation E.190 describes the general principles to be utilized in the assignment of ITU-T E-series international numbering resources. The procedures in this Recommendation, E.212, were developed in accordance with the principles contained in Recommendation E.190, and the statements contained in Recommendation E.190 take precedence over Recommendation E.212." The scope of E.212 is: "This Recommendation describes an international identification plan for mobile terminals or mobile users of public networks enabling roaming capabilities. It also establishes procedures for the assignment of International Mobile Subscriber Identities (IMSIs) to the mobile terminals and mobile users of such networks. This Recommendation describes the format of the IMSI." It is also noted there that: "an IMSI could be used to identify a UPT user or a subscriber to mobility services, as well as to identify a mobile terminal." A reference to E.212 from the ITU web site is: "[E.212] Recommendation E.212 (11/98) - The international identification plan for mobile terminals and mobile users." 4. Other comments: a. As Fred Baker said in an email, "... fundamentally, I think the ITU folks wanted to make sure that IETF use of "IMSI" and theirs correspond ...". I agree. b. The revisions to E.212 may be of interest to the IETF. c. I am not aware of any other Workshop-related issues for E.212 except for referencing the current version of the document. d. I am not aware of issues relevant to E.214, at least in ITU-T SG2, and there's not been any recent work on it there. Perhaps whoever suggested adding E.214 to the Related Work section of the Workshop matrix could identify if there are any issues that do fall within the Workshop's focus on Numbering, Naming, Addressing, and Routing. -Andy Gallant _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 15:43:25 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10654 for ; Tue, 8 Feb 2000 15:43:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26457 for ; Tue, 8 Feb 2000 15:41:54 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10649; Tue, 8 Feb 2000 15:43:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26439; Tue, 8 Feb 2000 15:41:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26414 for ; Tue, 8 Feb 2000 15:41:49 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10634 for ; Tue, 8 Feb 2000 15:43:17 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA14506; Tue, 8 Feb 2000 12:32:36 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id MAA25777; Tue, 8 Feb 2000 12:46:14 -0800 Message-Id: <4.1.20000208122147.040b1e60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Feb 2000 12:22:30 -0800 To: Andrew.Gallant@comsat.com From: Fred Baker Cc: itu+ietf@ietf.org, "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" In-Reply-To: <0000A267.C22219@comsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ITU+IETF] Re: comments on workshop issue 7 (E.212 IMSIs ...) - long Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org OK, so give me the executive summary: what do you want ITU to do? what do you want IETF to do? _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 16:11:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11250 for ; Tue, 8 Feb 2000 16:11:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27229 for ; Tue, 8 Feb 2000 16:10:28 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11245; Tue, 8 Feb 2000 16:11:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27208; Tue, 8 Feb 2000 16:10:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27174 for ; Tue, 8 Feb 2000 16:10:19 -0500 (EST) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11237 for ; Tue, 8 Feb 2000 16:11:48 -0500 (EST) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 8 Feb 2000 16:11:05 -0500 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0000A523; Tue, 8 Feb 2000 16:11:33 -0800 Mime-Version: 1.0 Date: Tue, 8 Feb 2000 16:10:58 -0800 Message-ID: <0000A523.C22277@comsat.com> To: Fred Baker Cc: itu+ietf@ietf.org, "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" Subject: Re: [ITU+IETF] Re: comments on workshop issue 7 (E.212 IMSIs Content-Type: multipart/mixed; boundary="IMA.Boundary.3905500590" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.3905500590 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit OK. I want IETF to make sure the current reference for E.212 IMSIs is used. I want whoever suggested E.214 to identify why. Based on your exec sum before I joined the list, you already handled alerting the IETF. (I assume our lists of I-Ds matched.) I invite whoever's interested to think about the "new" E.212. Finally, if anyone finds "NNAR" problems related to E.212/IMSIs, please advise. ______________________________ Reply Separator _________________________________ Subject: [ITU+IETF] Re: comments on workshop issue 7 (E.212 IMSIs ... Author: Fred Baker at INTERNET Date: 2/8/00 12:22 PM OK, so give me the executive summary: what do you want ITU to do? what do you want IETF to do? _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf --IMA.Boundary.3905500590 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from ro ([134.133.40.45]) by cqgate6.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 0000A356; Tue, 8 Feb 2000 15:47:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ro with esmtp (Exim 2.12 #8) id 12IHRq-00002q-00 for Andrew.Gallant@comsat.com; Tue, 8 Feb 2000 15:41:22 -0500 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26435; Tue, 8 Feb 2000 15:41:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26414 for ; Tue, 8 Feb 2000 15:41:49 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10634 for ; Tue, 8 Feb 2000 15:43:17 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA14506; Tue, 8 Feb 2000 12:32:36 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id MAA25777; Tue, 8 Feb 2000 12:46:14 -0800 Message-Id: <4.1.20000208122147.040b1e60@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Feb 2000 12:22:30 -0800 To: Andrew.Gallant@comsat.com From: Fred Baker Cc: itu+ietf@ietf.org, "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" In-Reply-To: <0000A267.C22219@comsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ITU+IETF] Re: comments on workshop issue 7 (E.212 IMSIs ...) - long Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org --IMA.Boundary.3905500590-- _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Tue Feb 8 19:43:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14109 for ; Tue, 8 Feb 2000 19:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04030 for ; Tue, 8 Feb 2000 19:42:07 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14104; Tue, 8 Feb 2000 19:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04002; Tue, 8 Feb 2000 19:42:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03977 for ; Tue, 8 Feb 2000 19:41:59 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14101 for ; Tue, 8 Feb 2000 19:43:29 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA03798; Tue, 8 Feb 2000 17:02:13 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id QAA25984; Tue, 8 Feb 2000 16:46:11 -0800 Message-Id: <4.1.20000208162521.01864be0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Feb 2000 16:30:14 -0800 To: Andrew.Gallant@comsat.com From: Fred Baker Subject: Re: [ITU+IETF] Re: comments on workshop issue 7 (E.212 IMSIs Cc: itu+ietf@ietf.org, "Ash; Gerald R (Jerry); ALARC" , Emad Qaddoura , Haseeb Akhtar , Mohamed Khalil , Raja Narayanan , "Shaw; Robert" , "'fredgaechter@monmouth.com'" , "Tar; John" In-Reply-To: <0000A523.C22277@comsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org At 04:10 PM 2/8/00 -0800, Andrew.Gallant@comsat.com wrote: > I want IETF to make sure the current reference for E.212 IMSIs is > used. Please give me the bibliographic text; I will make it available to the relevant authors. > I want whoever suggested E.214 to identify why. I checked up on it because issue 7, as discussed during the workshop, calls out E.212 and E.214. Do you have a problem with issue 7? Should references to E.214 also include references to E.212, be replaced by references to E.212, what? > I invite whoever's interested to think about the "new" E.212. I have no idea what you are talking about. How many E.212s has the ITU got? Last I checked, the ITU assigns one designator to one document, which it may periodically update. Am I incorrect? _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Wed Feb 9 12:29:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11811 for ; Wed, 9 Feb 2000 12:29:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15381 for ; Wed, 9 Feb 2000 12:28:13 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11806; Wed, 9 Feb 2000 12:29:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15335; Wed, 9 Feb 2000 12:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15315 for ; Wed, 9 Feb 2000 12:27:42 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11791 for ; Wed, 9 Feb 2000 12:29:07 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA02056; Wed, 9 Feb 2000 09:18:55 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id JAA26037; Wed, 9 Feb 2000 09:32:58 -0800 Message-Id: <4.1.20000209091224.022fb400@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Feb 2000 09:14:09 -0800 To: "Dayao, Al" From: Fred Baker Cc: itu+ietf@ietf.org In-Reply-To: <905DD86907DAD3119DE70000778D770F184D2B@mailsrv1.itu.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ITU+IETF] Re: IP-Telecoms Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org At 10:05 AM 2/9/00 +0100, Dayao, Al wrote: >The ITU-T Recommendations E.164, E.212 and Supplements 1&2 to E.164 are now >available on the IP-Telecoms page. >( http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm ) Access to the >documents is restricted to the Working Group. How is that useful to the IETF contributors you are trying to make it available to? Are you asking me to post my name and password to the various telephony-related mailing lists, notably enum? _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Wed Feb 9 14:30:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19023 for ; Wed, 9 Feb 2000 14:30:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20051 for ; Wed, 9 Feb 2000 14:29:29 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19018; Wed, 9 Feb 2000 14:30:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20022; Wed, 9 Feb 2000 14:29:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19848 for ; Wed, 9 Feb 2000 14:24:15 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18676 for ; Wed, 9 Feb 2000 14:25:37 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA26066; Wed, 9 Feb 2000 11:45:07 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id LAA26076; Wed, 9 Feb 2000 11:27:27 -0800 Message-Id: <4.1.20000209111812.00ab9b30@flipper.cisco.com> X-Sender: fred@flipper.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Feb 2000 11:22:17 -0800 To: acasati@lucent.com, afifi@sophia.inria.fr, becker@nortelnetworks.com, bound@zk3.dec.com, bpatil@nortelnetworks.com, charles.perkins@eng.sun.com, chuah@lucent.com, emadq@nortelnetworks.com, grai@lucent.com, grosser@us.ibm.com, haseeb@nortelnetworks.com, jacobt@livingston.com, jinwang@lucent.com, lode.coene@siemens.atea.be, lode.coene@vnet.atea.be, mccap@lucent.com, mkhalil@nortelnetworks.com, pcalhoun@eng.sun.com, raja@nortelnetworks.com, randy@qualcomm.com, scott@cadzow.com, tomhiller@lucent.com From: Fred Baker Subject: Fwd: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - long Cc: itu+ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Folks: You are the authors of various drafts and RFCs before the house. ITU SG2 has requested (well, not in so many words, but this is what they want) that in your next revision of your documents, you include the reference to E.212 found near the end of this note, point to it at your first use of the acronym "IMSI", and that you review the current E.212 document to make sure that your proposal is in keeping with the current specification. It might be worth your while to run that update by Mr. Gallant for comment when you make the change. Thanks for looking into that. Fred >From: Andrew.Gallant@comsat.com >Date: Tue, 8 Feb 2000 14:47:21 -0800 >To: itu+ietf@ietf.org >Cc: "Ash; Gerald R (Jerry); ALARC" , > Emad Qaddoura , > Haseeb Akhtar , > Mohamed Khalil , > Raja Narayanan , > "Shaw; Robert" , > "'fredgaechter@monmouth.com'" , > "Tar; John" , Fred Baker >Subject: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - long >Sender: itu+ietf-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: Joint ITU+IETF Discussion List >X-BeenThere: itu+ietf@ietf.org >X-SMTP-HELO: ietf.org >X-SMTP-MAIL-FROM: itu+ietf-admin@ietf.org >X-SMAP-Received-From: outside >X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] > > This is a set of comments on Workshop Issue 7 (E.212 IMSIs ...), and > consists of: > > - description, > - search results, > - information on E.212, and > - other comments. > > 1. From the Workshop Report, the description of Issue 7 is: > > - Issue #: 7 > - Issue Title: E.212 - IMSIs & mobility with IP > - Issue Description: In IETF documents, IMSI's are > mentioned but ITU-T Rec E.212 > is not often referenced. A review > of the IETF documents is > needed to ensure that the > appropriate use of the term > IMSI is used. > - Related Work: Rec. E.212 > Rec. E.214 > 3GPP > 3GPP2 > - Responsible Forum: IETF > > 2. Internet Drafts and RFCs were searched for mentions of E.212 and > IMSIs. The search results were: > > - For E.212: 2 Internet Drafts > 0 RFCs > - For IMSI: 6 Internet Drafts > 1 RFC (current > > The Internet Drafts mentioning E.212 were: > > - SS7 over internet applicability statement > (draft-coene-ss7-over-ip-00.txt) and > - Internet and SS7 addressing > (draft-coene-ss7-IP-addr-00.txt). > > The Internet Drafts mentioning IMSI were: > > - Transparent Hierarchical Mobility Agents (THEMA) > (draft-mccann-thema-00.txt) > - Support of IPv6 over Cellular Communications Systems (6Tel) > (draft-afifi-sixtel-00.txt) > - IP Mobility Architecture Framework > (draft-ietf-mobileip-ipm-arch-00.txt) > - IP Mobility Architecture Framework > (draft-becker-mobileip-ipm-arch-00.txt) > - Key Exchange for Network Architectures (KENA) > (draft-mkhalil-mobileip-kena-00.txt) > - Mobile PPP (MPPP) > (draft-ietf-pppext-mppp-01.txt) > > The RFC mentioning IMSI was: Wireless Device Configuration > (OTASP/OTAPA) via ACAP (RFC2636). > > 3. Recommendation E.212 was revised by ITU-T Study Group 2 in 1998. > The title is "THE INTERNATIONAL IDENTIFICATION PLAN FOR MOBILE > TERMINALS AND MOBILE USERS." The revision reflects the more general > scope of the term IMSI ("international mobile subscriber identity" -- > formerly known as the "international mobile station identity") and > what IMSIs could be used for. > > The "Table of Contents and Summary of Recommendation E.212 (11/98)" > may be found at "http://www.itu.int/itudoc/itu-t/rec/e/s_e212.html". > The summary is": > > "A plan for unique international identification of mobile terminals > and mobile users is required in order to enable these terminals and > users to roam among public networks which offer mobility services. > International Mobile Subscriber Identity (IMSI) is required so that a > visited network can identify a roaming mobile terminal or mobile user, > e.g. in order to query a subscriber's home network for subscription > and billing information. > > "Recommendation E.190 describes the general principles to be > utilized in the assignment of ITU-T E-series international numbering > resources. The procedures in this Recommendation, E.212, were > developed in accordance with the principles contained in > Recommendation E.190, and the statements contained in Recommendation > E.190 take precedence over Recommendation E.212." > > The scope of E.212 is: "This Recommendation describes an > international identification plan for mobile terminals or mobile users > of public networks enabling roaming capabilities. It also establishes > procedures for the assignment of International Mobile Subscriber > Identities (IMSIs) to the mobile terminals and mobile users of such > networks. This Recommendation describes the format of the IMSI." > > It is also noted there that: "an IMSI could be used to identify a UPT > user or a subscriber to mobility services, as well as to identify a > mobile terminal." > > A reference to E.212 from the ITU web site is: "[E.212] > Recommendation E.212 (11/98) - The international identification plan > for mobile terminals and mobile users." > > 4. Other comments: > > a. As Fred Baker said in an email, "... fundamentally, I think the > ITU folks wanted to make sure that IETF use of "IMSI" and theirs > correspond ...". I agree. > b. The revisions to E.212 may be of interest to the IETF. > c. I am not aware of any other Workshop-related issues for E.212 > except for referencing the current version of the document. > d. I am not aware of issues relevant to E.214, at least in ITU-T SG2, > and there's not been any recent work on it there. Perhaps whoever > suggested adding E.214 to the Related Work section of the Workshop > matrix could identify if there are any issues that do fall within the > Workshop's focus on Numbering, Naming, Addressing, and Routing. > > -Andy Gallant > > >_______________________________________________ >ITU+IETF mailing list >ITU+IETF@ietf.org >http://www.ietf.org/mailman/listinfo/itu+ietf =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Fred Baker | 519 Lado Drive IETF Chair | Santa Barbara California 93111 www.ietf.org | Desk: +1-408-526-4257 | Mobile: +1-805-886-3873 | FAX: +1-413-473-2403 _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Wed Feb 9 15:02:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20674 for ; Wed, 9 Feb 2000 15:02:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21339 for ; Wed, 9 Feb 2000 15:01:05 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20669; Wed, 9 Feb 2000 15:02:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21289; Wed, 9 Feb 2000 15:00:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21263 for ; Wed, 9 Feb 2000 15:00:53 -0500 (EST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19873; Wed, 9 Feb 2000 14:48:39 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Wed, 9 Feb 2000 13:48:47 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <13LQKB3X>; Wed, 9 Feb 2000 13:48:02 -0600 Message-ID: From: "Emad Qaddoura" To: "'Fred Baker'" Cc: itu+ietf@ietf.org, "Carey Becker" , "Haseeb Akhtar" , "Mohamed Khalil" , "Raja Narayanan" , "Monling Liao" Subject: RE: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - l ong Date: Wed, 9 Feb 2000 13:48:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7336.92B4AEEA" X-Orig: Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org 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_01BF7336.92B4AEEA Content-Type: text/plain; charset="ISO-8859-1" Hi Fred, When we are ready for a new revision, we will apply your comments below. Thanks, Emad. > -----Original Message----- > From: Fred Baker [mailto:chair@ietf.org] > Sent: Wednesday, February 09, 2000 1:22 PM > To: acasati@lucent.com; afifi@sophia.inria.fr; Becker, Carey > [RICH2:2N10-M:EXCH]; bound@zk3.dec.com; bpatil@nortelnetworks.com; > charles.perkins@eng.sun.com; chuah@lucent.com; Qaddoura, Emad > [RICH2:IP10-M:EXCH]; grai@lucent.com; grosser@us.ibm.com; > Akhtar, Haseeb > [RICH1:IP15:EXCH]; jacobt@livingston.com; jinwang@lucent.com; > lode.coene@siemens.atea.be; lode.coene@vnet.atea.be; mccap@lucent.com; > Khalil, Mohamed [RICH2:IP15:EXCH]; pcalhoun@eng.sun.com; > Narayanan, Raja > [RICH1:IP14:EXCH]; randy@qualcomm.com; scott@cadzow.com; > tomhiller@lucent.com > Cc: itu+ietf@ietf.org > Subject: Fwd: [ITU+IETF] comments on workshop issue 7 (E.212 > IMSIs ...) > - long > > > Folks: > > You are the authors of various drafts and RFCs before the > house. ITU SG2 > has requested (well, not in so many words, but this is what > they want) that > in your next revision of your documents, you include the > reference to E.212 > found near the end of this note, point to it at your first use of the > acronym "IMSI", and that you review the current E.212 > document to make sure > that your proposal is in keeping with the current specification. > > It might be worth your while to run that update by Mr. > Gallant for comment > when you make the change. > > Thanks for looking into that. > > Fred > > >From: Andrew.Gallant@comsat.com > >Date: Tue, 8 Feb 2000 14:47:21 -0800 > >To: itu+ietf@ietf.org > >Cc: "Ash; Gerald R (Jerry); ALARC" , > > Emad Qaddoura , > > Haseeb Akhtar , > > Mohamed Khalil , > > Raja Narayanan , > > "Shaw; Robert" , > > "'fredgaechter@monmouth.com'" , > > "Tar; John" , Fred Baker > >Subject: [ITU+IETF] comments on workshop issue 7 (E.212 > IMSIs ...) - long > >Sender: itu+ietf-admin@ietf.org > >X-Mailman-Version: 1.0 > >List-Id: Joint ITU+IETF Discussion List > >X-BeenThere: itu+ietf@ietf.org > >X-SMTP-HELO: ietf.org > >X-SMTP-MAIL-FROM: itu+ietf-admin@ietf.org > >X-SMAP-Received-From: outside > >X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] > > > > This is a set of comments on Workshop Issue 7 (E.212 > IMSIs ...), and > > consists of: > > > > - description, > > - search results, > > - information on E.212, and > > - other comments. > > > > 1. From the Workshop Report, the description of Issue 7 is: > > > > - Issue #: 7 > > - Issue Title: E.212 - IMSIs & mobility with IP > > - Issue Description: In IETF documents, IMSI's are > > mentioned but ITU-T Rec E.212 > > is not often referenced. A review > > of the IETF documents is > > needed to ensure that the > > appropriate use of the term > > IMSI is used. > > - Related Work: Rec. E.212 > > Rec. E.214 > > 3GPP > > 3GPP2 > > - Responsible Forum: IETF > > > > 2. Internet Drafts and RFCs were searched for mentions > of E.212 and > > IMSIs. The search results were: > > > > - For E.212: 2 Internet Drafts > > 0 RFCs > > - For IMSI: 6 Internet Drafts > > 1 RFC (current > > > > The Internet Drafts mentioning E.212 were: > > > > - SS7 over internet applicability statement > > (draft-coene-ss7-over-ip-00.txt) and > > - Internet and SS7 addressing > > (draft-coene-ss7-IP-addr-00.txt). > > > > The Internet Drafts mentioning IMSI were: > > > > - Transparent Hierarchical Mobility Agents (THEMA) > > (draft-mccann-thema-00.txt) > > - Support of IPv6 over Cellular Communications Systems (6Tel) > > (draft-afifi-sixtel-00.txt) > > - IP Mobility Architecture Framework > > (draft-ietf-mobileip-ipm-arch-00.txt) > > - IP Mobility Architecture Framework > > (draft-becker-mobileip-ipm-arch-00.txt) > > - Key Exchange for Network Architectures (KENA) > > (draft-mkhalil-mobileip-kena-00.txt) > > - Mobile PPP (MPPP) > > (draft-ietf-pppext-mppp-01.txt) > > > > The RFC mentioning IMSI was: Wireless Device Configuration > > (OTASP/OTAPA) via ACAP (RFC2636). > > > > 3. Recommendation E.212 was revised by ITU-T Study > Group 2 in 1998. > > The title is "THE INTERNATIONAL IDENTIFICATION PLAN FOR MOBILE > > TERMINALS AND MOBILE USERS." The revision reflects the > more general > > scope of the term IMSI ("international mobile > subscriber identity" -- > > formerly known as the "international mobile station > identity") and > > what IMSIs could be used for. > > > > The "Table of Contents and Summary of Recommendation > E.212 (11/98)" > > may be found at > "http://www.itu.int/itudoc/itu-t/rec/e/s_e212.html". > > The summary is": > > > > "A plan for unique international identification of > mobile terminals > > and mobile users is required in order to enable these > terminals and > > users to roam among public networks which offer > mobility services. > > International Mobile Subscriber Identity (IMSI) is > required so that a > > visited network can identify a roaming mobile terminal > or mobile user, > > e.g. in order to query a subscriber's home network for > subscription > > and billing information. > > > > "Recommendation E.190 describes the general principles to be > > utilized in the assignment of ITU-T E-series > international numbering > > resources. The procedures in this Recommendation, E.212, were > > developed in accordance with the principles contained in > > Recommendation E.190, and the statements contained in > Recommendation > > E.190 take precedence over Recommendation E.212." > > > > The scope of E.212 is: "This Recommendation describes an > > international identification plan for mobile terminals > or mobile users > > of public networks enabling roaming capabilities. It > also establishes > > procedures for the assignment of International Mobile > Subscriber > > Identities (IMSIs) to the mobile terminals and mobile > users of such > > networks. This Recommendation describes the format of the IMSI." > > > > It is also noted there that: "an IMSI could be used to > identify a UPT > > user or a subscriber to mobility services, as well as > to identify a > > mobile terminal." > > > > A reference to E.212 from the ITU web site is: "[E.212] > > Recommendation E.212 (11/98) - The international > identification plan > > for mobile terminals and mobile users." > > > > 4. Other comments: > > > > a. As Fred Baker said in an email, "... fundamentally, > I think the > > ITU folks wanted to make sure that IETF use of "IMSI" > and theirs > > correspond ...". I agree. > > b. The revisions to E.212 may be of interest to the IETF. > > c. I am not aware of any other Workshop-related issues > for E.212 > > except for referencing the current version of the document. > > d. I am not aware of issues relevant to E.214, at > least in ITU-T SG2, > > and there's not been any recent work on it there. > Perhaps whoever > > suggested adding E.214 to the Related Work section of > the Workshop > > matrix could identify if there are any issues that do > fall within the > > Workshop's focus on Numbering, Naming, Addressing, and Routing. > > > > -Andy Gallant > > > > > >_______________________________________________ > >ITU+IETF mailing list > >ITU+IETF@ietf.org > >http://www.ietf.org/mailman/listinfo/itu+ietf > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Fred Baker | 519 Lado Drive > IETF Chair | Santa Barbara California 93111 > www.ietf.org | Desk: +1-408-526-4257 > | Mobile: +1-805-886-3873 > | FAX: +1-413-473-2403 > ------_=_NextPart_001_01BF7336.92B4AEEA Content-Type: text/html; charset="ISO-8859-1" RE: [ITU+IETF] comments on workshop issue 7 (E.212 IMSIs ...) - long

Hi Fred,

        When we are ready for a new revision, we will apply your comments below.

Thanks,
Emad.

> -----Original Message-----
> From: Fred Baker [mailto:chair@ietf.org]
> Sent: Wednesday, February 09, 2000 1:22 PM
> To: acasati@lucent.com; afifi@sophia.inria.fr; Becker, Carey
> [RICH2:2N10-M:EXCH]; bound@zk3.dec.com; bpatil@nortelnetworks.com;
> charles.perkins@eng.sun.com; chuah@lucent.com; Qaddoura, Emad
> [RICH2:IP10-M:EXCH]; grai@lucent.com; grosser@us.ibm.com;
> Akhtar, Haseeb
> [RICH1:IP15:EXCH]; jacobt@livingston.com; jinwang@lucent.com;
> lode.coene@siemens.atea.be; lode.coene@vnet.atea.be; mccap@lucent.com;
> Khalil, Mohamed [RICH2:IP15:EXCH]; pcalhoun@eng.sun.com;
> Narayanan, Raja
> [RICH1:IP14:EXCH]; randy@qualcomm.com; scott@cadzow.com;
> tomhiller@lucent.com
> Cc: itu+ietf@ietf.org
> Subject: Fwd: [ITU+IETF] comments on workshop issue 7 (E.212
> IMSIs ...)
> - long
>
>
> Folks:
>
> You are the authors of various drafts and RFCs before the
> house. ITU SG2
> has requested (well, not in so many words, but this is what
> they want) that
> in your next revision of your documents, you include the
> reference to E.212
> found near the end of this note, point to it at your first use of the
> acronym "IMSI", and that you review the current E.212
> document to make sure
> that your proposal is in keeping with the current specification.
>
> It might be worth your while to run that update by Mr.
> Gallant for comment
> when you make the change.
>
> Thanks for looking into that.
>
> Fred
>
> >From: Andrew.Gallant@comsat.com
> >Date: Tue, 8 Feb 2000 14:47:21 -0800
> >To: itu+ietf@ietf.org
> >Cc: "Ash; Gerald R (Jerry); ALARC" <gash@att.com>,
> >        Emad Qaddoura <emadq@nortelnetworks.com>,
> >        Haseeb Akhtar <haseeb@nortelnetworks.com>,
> >        Mohamed Khalil <mkhalil@nortelnetworks.com>,
> >        Raja Narayanan <raja@nortelnetworks.com>,
> >        "Shaw; Robert" <Robert.Shaw@itu.int>,
> >        "'fredgaechter@monmouth.com'" <fredgaechter@monmouth.com>,
> >        "Tar; John" <John.Tar@itu.int>, Fred Baker <fred@cisco.com>
> >Subject: [ITU+IETF] comments on workshop issue 7 (E.212
> IMSIs ...) - long
> >Sender: itu+ietf-admin@ietf.org
> >X-Mailman-Version: 1.0
> >List-Id: Joint ITU+IETF Discussion List <itu+ietf.ietf.org>
> >X-BeenThere: itu+ietf@ietf.org
> >X-SMTP-HELO: ietf.org
> >X-SMTP-MAIL-FROM: itu+ietf-admin@ietf.org
> >X-SMAP-Received-From: outside
> >X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176]
> >
> >     This is a set of comments on Workshop Issue 7 (E.212
> IMSIs ...), and
> >     consists of:
> >    
> >     -  description,
> >     -  search results,
> >     -  information on E.212, and
> >     -  other comments.
> >    
> >     1.  From the Workshop Report, the description of Issue 7 is:
> >    
> >     -  Issue #:               7
> >     -  Issue Title:           E.212 - IMSIs & mobility with IP
> >     -  Issue Description:     In IETF documents, IMSI's are
> >                               mentioned but ITU-T Rec E.212
> >                               is not often referenced. A review
> >                               of the IETF documents is
> >                               needed to ensure that the
> >                               appropriate use of the term
> >                               IMSI is used.
> >     -  Related Work:          Rec. E.212
> >                               Rec. E.214
> >                               3GPP
> >                               3GPP2
> >     -  Responsible Forum:     IETF
> >    
> >     2.  Internet Drafts and RFCs were searched for mentions
> of E.212 and
> >     IMSIs.  The search results were:
> >    
> >     -  For E.212:             2 Internet Drafts
> >                               0 RFCs
> >     -  For IMSI:              6 Internet Drafts
> >                               1 RFC (current
> >    
> >     The Internet Drafts mentioning E.212 were:
> >    
> >     -  SS7 over internet applicability statement
> >        (draft-coene-ss7-over-ip-00.txt) and
> >     -  Internet and SS7 addressing
> >        (draft-coene-ss7-IP-addr-00.txt).
> >    
> >     The Internet Drafts mentioning IMSI were:
> >    
> >     -  Transparent Hierarchical Mobility Agents (THEMA)
> >        (draft-mccann-thema-00.txt)
> >     -  Support of IPv6 over Cellular Communications Systems (6Tel)
> >        (draft-afifi-sixtel-00.txt)
> >     -  IP Mobility Architecture Framework
> >        (draft-ietf-mobileip-ipm-arch-00.txt)
> >     -  IP Mobility Architecture Framework
> >        (draft-becker-mobileip-ipm-arch-00.txt)
> >     -  Key Exchange for Network Architectures (KENA)
> >        (draft-mkhalil-mobileip-kena-00.txt)
> >     -  Mobile PPP (MPPP)
> >        (draft-ietf-pppext-mppp-01.txt)
> >    
> >     The RFC mentioning IMSI was:  Wireless Device Configuration
> >     (OTASP/OTAPA) via ACAP (RFC2636).
> >    
> >     3.  Recommendation E.212 was revised by ITU-T Study
> Group 2 in 1998. 
> >     The title is "THE INTERNATIONAL IDENTIFICATION PLAN FOR MOBILE
> >     TERMINALS AND MOBILE USERS."  The revision reflects the
> more general
> >     scope of the term IMSI ("international mobile
> subscriber identity" --
> >     formerly known as the "international mobile station
> identity") and
> >     what IMSIs could be used for.
> >    
> >     The "Table of Contents and Summary of Recommendation
> E.212 (11/98)"
> >     may be found at
> "http://www.itu.int/itudoc/itu-t/rec/e/s_e212.html". 
> >     The summary is":
> >    
> >       "A plan for unique international identification of
> mobile terminals
> >     and mobile users is required in order to enable these
> terminals and
> >     users to roam among public networks which offer
> mobility services.
> >     International Mobile Subscriber Identity (IMSI) is
> required so that a
> >     visited network can identify a roaming mobile terminal
> or mobile user,
> >     e.g. in order to query a subscriber's home network for
> subscription
> >     and billing information.
> >    
> >       "Recommendation E.190 describes the general principles to be
> >     utilized in the assignment of ITU-T E-series
> international numbering
> >     resources. The procedures in this Recommendation, E.212, were
> >     developed in accordance with the principles contained in
> >     Recommendation E.190, and the statements contained in
> Recommendation
> >     E.190 take precedence over Recommendation E.212."
> >    
> >     The scope of E.212 is:  "This Recommendation describes an
> >     international identification plan for mobile terminals
> or mobile users
> >     of public networks enabling roaming capabilities. It
> also establishes
> >     procedures for the assignment of International Mobile
> Subscriber
> >     Identities (IMSIs) to the mobile terminals and mobile
> users of such
> >     networks. This Recommendation describes the format of the IMSI."
> >    
> >     It is also noted there that:  "an IMSI could be used to
> identify a UPT
> >     user or a subscriber to mobility services, as well as
> to identify a
> >     mobile terminal."
> >    
> >     A reference to E.212 from the ITU web site is:  "[E.212]
> >     Recommendation E.212 (11/98) - The international
> identification plan
> >     for mobile terminals and mobile users."
> >    
> >     4.  Other comments:
> >    
> >     a.  As Fred Baker said in an email, "... fundamentally,
> I think the
> >     ITU folks wanted to make sure that IETF use of "IMSI"
> and theirs
> >     correspond ...".  I agree.
> >     b.  The revisions to E.212 may be of interest to the IETF.
> >     c.  I am not aware of any other Workshop-related issues
> for E.212
> >     except for referencing the current version of the document.
> >     d.  I am not aware of issues relevant to E.214, at
> least in ITU-T SG2,
> >     and there's not been any recent work on it there. 
> Perhaps whoever
> >     suggested adding E.214 to the Related Work section of
> the Workshop
> >     matrix could identify if there are any issues that do
> fall within the
> >     Workshop's focus on Numbering, Naming, Addressing, and Routing.
> >    
> >     -Andy Gallant
> >    
> >
> >_______________________________________________
> >ITU+IETF mailing list
> >ITU+IETF@ietf.org
> >http://www.ietf.org/mailman/listinfo/itu+ietf
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Fred Baker    | 519 Lado Drive
> IETF Chair    | Santa Barbara California 93111
> www.ietf.org  | Desk:   +1-408-526-4257
>               | Mobile: +1-805-886-3873
>               | FAX:    +1-413-473-2403
>

------_=_NextPart_001_01BF7336.92B4AEEA-- _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Thu Feb 10 03:04:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17221 for ; Thu, 10 Feb 2000 03:04:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17466 for ; Thu, 10 Feb 2000 03:02:56 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17216; Thu, 10 Feb 2000 03:04:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17437; Thu, 10 Feb 2000 03:02:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17414 for ; Thu, 10 Feb 2000 03:02:40 -0500 (EST) Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17213 for ; Thu, 10 Feb 2000 03:04:09 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id <1TJB396C>; Thu, 10 Feb 2000 09:04:56 +0100 Message-ID: <905DD86907DAD3119DE70000778D770F184D84@mailsrv1.itu.ch> From: "Dayao, Al" To: "'Fred Baker'" , "Dayao, Al" Cc: itu+ietf@ietf.org Date: Thu, 10 Feb 2000 09:03:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ITU+IETF] RE: IP-Telecoms Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Dear Sir, I sent to each of the participants of the workshop their own usernames and passwords. Regards, Al S. Dayao Telecommunication Standardization Bureau International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland Tel: +41 22 730 5859 Fax: +41 22 730 5853 Email: al.dayao@itu.int -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Wednesday, February 09, 2000 18:14 To: Dayao, Al Cc: itu+ietf@ietf.org Subject: Re: IP-Telecoms At 10:05 AM 2/9/00 +0100, Dayao, Al wrote: >The ITU-T Recommendations E.164, E.212 and Supplements 1&2 to E.164 are now >available on the IP-Telecoms page. >( http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm ) Access to the >documents is restricted to the Working Group. How is that useful to the IETF contributors you are trying to make it available to? Are you asking me to post my name and password to the various telephony-related mailing lists, notably enum? _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Thu Feb 10 03:35:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17484 for ; Thu, 10 Feb 2000 03:35:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18241 for ; Thu, 10 Feb 2000 03:33:36 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17479; Thu, 10 Feb 2000 03:35:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18216; Thu, 10 Feb 2000 03:33:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18197 for ; Thu, 10 Feb 2000 03:33:19 -0500 (EST) Received: from mail1.itu.int (mail1.itu.ch [156.106.192.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17473 for ; Thu, 10 Feb 2000 03:34:48 -0500 (EST) Received: by mail1.itu.ch with Internet Mail Service (5.5.2650.21) id <1TJB30CV>; Thu, 10 Feb 2000 09:35:37 +0100 Message-ID: <905DD86907DAD3119DE70000778D770F1AC0D0@mailsrv1.itu.ch> From: "Tar, John" To: "'Fred Baker'" Cc: itu+ietf@ietf.org Subject: RE: [ITU+IETF] Re: IP-Telecoms Date: Thu, 10 Feb 2000 09:34:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Dear Fred, Perhaps in our haste to make these Recommendations and Supplements available to all Workshop participants,we erred in not explaining clearly that everyone of the registered participants at the recent IP-Telecoms Workshop was given their own individual username and password,so they all have free [i.e.at no charge] access to these texts. I thought that this course of action was a reasonable compromise between ITU's official publication policy [which I am not at liberty to change] and the ITU's need to excercise flexibility in our collaborative work with the IETF,which I regard as very important and mutually beneficial. Kind Regards, John Tar > -----Original Message----- > From: Fred Baker [SMTP:fred@cisco.com] > Sent: Wednesday, February 09, 2000 6:14 PM > To: Dayao, Al > Cc: itu+ietf@ietf.org > Subject: [ITU+IETF] Re: IP-Telecoms > > At 10:05 AM 2/9/00 +0100, Dayao, Al wrote: > >The ITU-T Recommendations E.164, E.212 and Supplements 1&2 to E.164 are > now > >available on the IP-Telecoms page. > >( http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm ) Access to the > >documents is restricted to the Working Group. > > How is that useful to the IETF contributors you are trying to make it > available to? Are you asking me to post my name and password to the > various > telephony-related mailing lists, notably enum? > > _______________________________________________ > ITU+IETF mailing list > ITU+IETF@ietf.org > http://www.ietf.org/mailman/listinfo/itu+ietf _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Thu Feb 10 14:29:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08360 for ; Thu, 10 Feb 2000 14:29:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08255 for ; Thu, 10 Feb 2000 14:28:22 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08355; Thu, 10 Feb 2000 14:29:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08201; Thu, 10 Feb 2000 14:27:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08185 for ; Thu, 10 Feb 2000 14:27:58 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08352 for ; Thu, 10 Feb 2000 14:29:25 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id MAA28942 for ; Thu, 10 Feb 2000 12:29:24 -0700 (MST)] Received: [from az33exi01.corp.mot.com ([199.2.84.10]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA29970 for ; Thu, 10 Feb 2000 12:29:24 -0700 (MST)] Received: by AZ33EXI01 with Internet Mail Service (5.5.2650.21) id <1FGKFVKL>; Thu, 10 Feb 2000 12:29:22 -0700 Message-ID: <87568F78ABDCD211A0AC0008C707718B01CB7F07@az10exm03.sat.mot.com> From: Das Swapan-P29237 To: "'itu+ietf@ietf.org'" Date: Thu, 10 Feb 2000 12:29:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ITU+IETF] (no subject) Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Thu Feb 17 10:37:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16055 for ; Thu, 17 Feb 2000 10:37:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08069 for ; Thu, 17 Feb 2000 10:35:27 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16050; Thu, 17 Feb 2000 10:37:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08030; Thu, 17 Feb 2000 10:35:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08009 for ; Thu, 17 Feb 2000 10:35:03 -0500 (EST) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16037 for ; Thu, 17 Feb 2000 10:36:38 -0500 (EST) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Thu, 17 Feb 2000 10:35:44 -0500 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0001045E; Thu, 17 Feb 2000 10:36:26 -0800 Mime-Version: 1.0 Date: Thu, 17 Feb 2000 10:33:41 -0800 Message-ID: <0001045E.C22277@comsat.com> To: itu+ietf@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Subject: [ITU+IETF] working on Issue 6 (E.164 ...) Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, list. I'm working on Issue 6 from the Workshop, "E.164, URLs, and 'Telephony'", and I'd like ask for some input from this list about which Internet-Drafts to look at. Quick context: (1) My (naive) searches of Internet-Drafts produced more than 60(!) hits on I-Ds that mention E.164. (2) ITU-T SG2 begins four days before the I-D cutoff date for Adelaide. (3) If work on Issue 6 did produce something of value by that time, then it could perhaps go to Adelaide in a new I-D. My question to list members: Which current Internet-Drafts mentioning E.164 should I (or anyone interested) look at? I'm looking for suggestions that identify I-Ds where constructive comments (if any) would be useful to IETF work. And, I'd be grateful for feedback to shorten/prioritize the list of I-Ds to read. Thanks. -Andy Gallant PS: Note that from: http://www.ietf.org/mail-archive/ietf-announce/msg06651.html "The IESG has approved the Internet-Draft 'URLs for Telephone Calls' as a Proposed Standard." _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf From itu+ietf-admin@ietf.org Fri Feb 25 06:48:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05306 for ; Fri, 25 Feb 2000 06:48:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22591 for ; Fri, 25 Feb 2000 06:46:28 -0500 (EST) Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05301; Fri, 25 Feb 2000 06:48:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22572; Fri, 25 Feb 2000 06:45:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22546 for ; Fri, 25 Feb 2000 06:45:51 -0500 (EST) Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05285 for ; Fri, 25 Feb 2000 06:47:35 -0500 (EST) Received: from xs3.xs4all.nl (phranck@xs3.xs4all.nl [194.109.6.44]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA20538 for ; Fri, 25 Feb 2000 12:47:24 +0100 (CET) Received: from localhost (phranck@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA06073 for ; Fri, 25 Feb 2000 12:47:24 +0100 (CET) Date: Fri, 25 Feb 2000 12:47:24 +0100 (CET) From: phranck To: itu+ietf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ITU+IETF] test message - please ignore Sender: itu+ietf-admin@ietf.org Errors-To: itu+ietf-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Joint ITU+IETF Discussion List X-BeenThere: itu+ietf@ietf.org _______________________________________________ ITU+IETF mailing list ITU+IETF@ietf.org http://www.ietf.org/mailman/listinfo/itu+ietf