From exim@www1.ietf.org Tue Jul 1 02:21:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15108 for ; Tue, 1 Jul 2003 02:21:22 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h616KsI00894 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 02:20:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEUl-00006h-0q; Tue, 01 Jul 2003 02:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEU6-00005q-2J for enum@optimus.ietf.org; Tue, 01 Jul 2003 02:19:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14918 for ; Tue, 1 Jul 2003 02:19:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XETx-0007dc-00 for enum@ietf.org; Tue, 01 Jul 2003 02:19:13 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19XETX-0007dB-00 for enum@ietf.org; Tue, 01 Jul 2003 02:18:47 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h616G2JE021588; Tue, 1 Jul 2003 08:16:04 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 08:18:06 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 08:18:06 +0200 Date: Tue, 1 Jul 2003 08:18:05 +0200 Subject: Re: [Enum] Official ENUM Related URL's Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org To: James Seng From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3EF5C5B6.8030100@pobox.org.sg> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 01 Jul 2003 06:18:06.0471 (UTC) FILETIME=[8920C170:01C33F98] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On s=F6ndag, jun 22, 2003, at 17:05 Europe/Stockholm, James Seng wrote: > Nice to see so many trials on-going but does anyone have any links to > any applications, products etc that actually uses ENUM? I have not seen any compilation. With my Cisco hat on: - Cisco IOS-based gateways use ENUM, and that is what I use in the =20 Swedish trial. - Cisco SIP Proxy Server (CSPS) uses ENUM, but it doesn't have so many =20= degrees of freedom as the IOS based ENUM code paf > > ps: I just got our 5.6.e164.arpa delegation for Singapore. > > -James Seng > > Richard Shockey wrote: >> This is the list I have of more or less "official" ENUM or ENUM trial = =20 >> related Web Sites etc. >> If anyone has others pass them along. >> The ENUM Forum in the United States >> http://www.enum-forum.org/ >> ENUM in Austria >> http://www.rtr.at/web.nsf/englisch/=20 >> Telekommunikation~Nummerierung~ENUM?OpenDocument ENUM in the UK >> http://www.dti.gov.uk/cii/regulatory/enum/egp_report.shtml >> http://www.dti.gov.uk/cii/regulatory/enum/ukeg20021108.ppt >> ENUM in France >> http://www.numerobis.prd.fr/welcome.shtml >> ENUM in Australia >> http://www.aca.gov.au/committee/nsg2/enum.htm >> ENUM in The Netherlands >> http://www.enuminnederland.nl >> ENUM in China >> http://www.enum.cn/index-en.html >> ENUM in Germany >> http://www.denic.de/enum/index.html >> ENUM in Switzerland >> http://www.ofcom.ch/en/telekommunikation/nummerierung/enum/ >> ENUM in Korea >> http://www.enum.or.kr/ >> In addition considerable information on the current status of ENUM =20= >> can be found at the ITU-T's web site >> http://www.itu.int/ITU-T/inr/enum/index.html >> and also at RIPE NCC's web site >> http://www.ripe.net/enum/ >> Some information on trials is at >> http://www.itu.int/ITU-T/inr/enum/trials.html >> This seems to be a list of current delegations in e164.arpa I cant =20= >> testify to its accuracy and there is no indication of when the page =20= >> was updated. >> http://www.enum.info/ENUM%20Matrix.htm >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Senior Manager, Strategic Technology Initiatives >> NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 >> or >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 02:30:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15547 for ; Tue, 1 Jul 2003 02:30:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h616U2102482 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 02:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEeQ-0000du-0Y; Tue, 01 Jul 2003 02:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEeE-0000d6-An for enum@optimus.ietf.org; Tue, 01 Jul 2003 02:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15499 for ; Tue, 1 Jul 2003 02:29:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XEe9-0007hW-00 for enum@ietf.org; Tue, 01 Jul 2003 02:29:45 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19XEdn-0007hL-00 for enum@ietf.org; Tue, 01 Jul 2003 02:29:23 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h616QQ1j022847; Tue, 1 Jul 2003 08:26:40 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 08:28:43 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 08:28:42 +0200 Date: Tue, 1 Jul 2003 08:28:40 +0200 Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Richard Shockey'" , enum@ietf.org To: "McCandless, Kevin" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <318266A4431BC549B4C4D6FD3EA6E24DBEF03D@ove1wnexm01.corp.illuminet.com> Message-Id: <417E15D0-AB8D-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 01 Jul 2003 06:28:42.0537 (UTC) FILETIME=[0440B990:01C33F9A] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm, McCandless, Kevin =20= wrote: > So, is DNSSEC within the scope of our discussions or not. During the =20= > last IETF meeting I thought I heard that DNSSEC is out of scope. My =20= > opinion is that DNSSEC is relevant when security issues are discussed =20= > for ENUM. I think I argued against DNSSEC, and I will still do it. Reasons are: - This wg is _not_ where DNSSEC specification is discussed, this wg is using the DNS protocol - DNSSEC development is behind ENUM, which means we can not have a mandatory to implement DNSSEC, as DNSSEC doesn't exists (or rather, doesn't work as specified) If we talk too much about DNSSEC, I am extremely nervous we dive into =20= trying to solve all problems with DNSSEC the DNS wg's are working with. That said, YES, it is _extremely_important_ we get some way of =20 verifying DNS records we get back when querying the DNS. Both for ENUM =20= and other applications. I take for granted _all_ users of DNS will start using DNSSEC as soon =20= as it is possible. ENUM is not an exception. paf > > Kevin... > >> -----Original Message----- >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] >> Sent: Monday, June 30, 2003 8:55 AM >> To: enum@ietf.org >> Subject: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt >> >> >> >> FYI >> >> >> A useful document to keep in mind considering our ongoing >> discussions of >> DNSSEC. >> >>> To: IETF-Announce: ; >>> Cc: namedroppers@ops.ietf.org >>> From: Internet-Drafts@ietf.org >>> Reply-to: Internet-Drafts@ietf.org >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 >>> Sender: owner-ietf-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the DNS Extensions Working >> Group of the IETF. >>> >>> Title : Threat Analysis Of The Domain Name System >>> Author(s) : D. Atkins, R. Austein >>> Filename : draft-ietf-dnsext-dns-threats-03.txt >>> Pages : 15 >>> Date : 2003-6-27 >>> >>> Although the DNS Security Extensions (DNSSEC) have been under >>> development for most of the last decade, the IETF has never written >>> down the specific set of threats against which DNSSEC is designed to >>> protect. Among other drawbacks, this cart-before-the-horse = situation >>> has made it difficult to determine whether DNSSEC meets its design >>> goals, since its design goals are not well specified. This note >>> attempts to document some of the known threats to the DNS, and, in >>> doing so, attempts to measure to what extent (if any) DNSSEC is a >>> useful tool in defending against these threats. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > eats-03.txt >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the =20= >> message. >> >> Internet-Drafts are also available by anonymous FTP. Login with the =20= >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-dnsext-dns-threats-03.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" =20= >> or >> a MIME-compliant mail reader. Different MIME-compliant mail =20= >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been =20 >> split >> up into multiple messages), so check your local documentation = =20 >> on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2003-6-27150122.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt >> >> > 03.txt> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > or =20 > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 02:35:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15726 for ; Tue, 1 Jul 2003 02:35:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h616Z2N04323 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 02:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEjF-00017L-81; Tue, 01 Jul 2003 02:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEjA-000174-9K for enum@optimus.ietf.org; Tue, 01 Jul 2003 02:34:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15687 for ; Tue, 1 Jul 2003 02:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XEj6-00000U-00 for enum@ietf.org; Tue, 01 Jul 2003 02:34:52 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19XEiv-00000L-00 for enum@ietf.org; Tue, 01 Jul 2003 02:34:41 -0400 Content-Class: urn:content-classes:message Subject: RE: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jul 2003 08:38:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620E9FA0@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Thread-Index: AcM/muZExiCv6RmpQr6DU+nC6yFq0QAAIEVQ From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "McCandless, Kevin" Cc: "Richard Shockey" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I fully agree with Patrik. IMHO dnssec should come up with a solution workable for all existing DNS applications and ENUM is one of them. So it is up to dnsext to solve the problem and enum WG may help if=20 required (requested). Richard > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 > Sent: Tuesday, July 01, 2003 8:29 AM > To: McCandless, Kevin > Cc: 'Richard Shockey'; enum@ietf.org > Subject: Re: [Enum] Fwd: I-D=20 > ACTION:draft-ietf-dnsext-dns-threats-03.txt >=20 >=20 > On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm,=20 > McCandless, Kevin =20 > wrote: >=20 > > So, is DNSSEC within the scope of our discussions or not. =20 > During the > > last IETF meeting I thought I heard that DNSSEC is out of=20 > scope. My =20 > > opinion is that DNSSEC is relevant when security issues are=20 > discussed =20 > > for ENUM. >=20 > I think I argued against DNSSEC, and I will still do it. >=20 > Reasons are: >=20 > - This wg is _not_ where DNSSEC specification is discussed, > this wg is using the DNS protocol > - DNSSEC development is behind ENUM, which means we can not > have a mandatory to implement DNSSEC, as DNSSEC doesn't > exists (or rather, doesn't work as specified) >=20 > If we talk too much about DNSSEC, I am extremely nervous we=20 > dive into =20 > trying to solve all problems with DNSSEC the DNS wg's are=20 > working with. >=20 > That said, YES, it is _extremely_important_ we get some way of =20 > verifying DNS records we get back when querying the DNS. Both=20 > for ENUM =20 > and other applications. >=20 > I take for granted _all_ users of DNS will start using DNSSEC=20 > as soon =20 > as it is possible. >=20 > ENUM is not an exception. >=20 > paf >=20 >=20 > > > > Kevin... > > > >> -----Original Message----- > >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] > >> Sent: Monday, June 30, 2003 8:55 AM > >> To: enum@ietf.org > >> Subject: [Enum] Fwd: I-D=20 > ACTION:draft-ietf-dnsext-dns-threats-03.txt > >> > >> > >> > >> FYI > >> > >> > >> A useful document to keep in mind considering our ongoing=20 > discussions=20 > >> of DNSSEC. > >> > >>> To: IETF-Announce: ; > >>> Cc: namedroppers@ops.ietf.org > >>> From: Internet-Drafts@ietf.org > >>> Reply-to: Internet-Drafts@ietf.org > >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 > >>> Sender: owner-ietf-announce@ietf.org > >>> > >>> > >>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>> directories. This draft is a work item of the DNS=20 > Extensions Working > >> Group of the IETF. > >>> > >>> Title : Threat Analysis Of The Domain=20 > Name System > >>> Author(s) : D. Atkins, R. Austein > >>> Filename : draft-ietf-dnsext-dns-threats-03.txt > >>> Pages : 15 > >>> Date : 2003-6-27 > >>> > >>> Although the DNS Security Extensions (DNSSEC) have been under=20 > >>> development for most of the last decade, the IETF has=20 > never written=20 > >>> down the specific set of threats against which DNSSEC is=20 > designed to=20 > >>> protect. Among other drawbacks, this cart-before-the-horse=20 > >>> situation has made it difficult to determine whether DNSSEC meets=20 > >>> its design goals, since its design goals are not well specified. =20 > >>> This note attempts to document some of the known threats=20 > to the DNS,=20 > >>> and, in doing so, attempts to measure to what extent (if=20 > any) DNSSEC=20 > >>> is a useful tool in defending against these threats. > >>> > >>> A URL for this Internet-Draft is:=20 > >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > > eats-03.txt > >> > >> To remove yourself from the IETF Announcement list, send a=20 > message to=20 > >> ietf-announce-request with the word unsubscribe in the body of the > >> message. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username > >> "anonymous" and a password of your e-mail address. After=20 > logging in, > >> type "cd internet-drafts" and then > >> "get draft-ietf-dnsext-dns-threats-03.txt". > >> > >> A list of Internet-Drafts directories can be found in=20 > >> http://www.ietf.org/shadow.html or=20 > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE=20 > /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. =20 > To use this > >> feature, insert the command "ENCODING mime" before=20 > the "FILE" > >> command. To decode the response(s), you will need=20 > "munpack" > >> or > >> a MIME-compliant mail reader. Different=20 > MIME-compliant mail =20 > >> readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been =20 > >> split > >> up into multiple messages), so check your local=20 > documentation =20 > >> on > >> how to manipulate these messages. > >> > >> > >> Below is the data which will enable a MIME compliant mail reader=20 > >> implementation to automatically retrieve the ASCII version of the=20 > >> Internet-Draft. > >> Content-Type: text/plain > >> Content-ID: <2003-6-27150122.I-D@ietf.org> > >> > >> ENCODING mime > >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt > >> > >> >> 03.txt> > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives=20 > > NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237=20 > > or > > > > ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 03:19:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15546 for ; Tue, 1 Jul 2003 02:30:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h616U2r02477 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 02:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEeP-0000dT-65; Tue, 01 Jul 2003 02:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XEeC-0000d1-LZ for enum@optimus.ietf.org; Tue, 01 Jul 2003 02:29:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15484 for ; Tue, 1 Jul 2003 02:29:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XEe4-0007hT-00 for enum@ietf.org; Tue, 01 Jul 2003 02:29:40 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19XEde-0007g5-00 for enum@ietf.org; Tue, 01 Jul 2003 02:29:15 -0400 Content-Class: urn:content-classes:message Subject: RE: [Enum] Official ENUM Related URL's MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jul 2003 08:32:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620E9F9E@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Official ENUM Related URL's Thread-Index: AcM/mX+GUQD2kUocTQG3qK+Ch9M2BQAAATng From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "James Seng" Cc: Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I thought I replied to this already, but obviosly not: The SIP Express Router (SER) from Jiri Kuthan (iptel.org - GMD/Fokus) = and also the Asterisk IP PBX from Mark Spencer is ENUM - enabled. Both are open source. Richard > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 > Sent: Tuesday, July 01, 2003 8:18 AM > To: James Seng > Cc: enum@ietf.org > Subject: Re: [Enum] Official ENUM Related URL's >=20 >=20 > On s=F6ndag, jun 22, 2003, at 17:05 Europe/Stockholm, James Seng = wrote: >=20 > > Nice to see so many trials on-going but does anyone have=20 > any links to=20 > > any applications, products etc that actually uses ENUM? >=20 > I have not seen any compilation. >=20 > With my Cisco hat on: > - Cisco IOS-based gateways use ENUM, and that is what I use in the =20 > Swedish trial. > - Cisco SIP Proxy Server (CSPS) uses ENUM, but it doesn't=20 > have so many =20 > degrees of freedom as the IOS based ENUM code >=20 > paf >=20 > > > > ps: I just got our 5.6.e164.arpa delegation for Singapore. > > > > -James Seng > > > > Richard Shockey wrote: > >> This is the list I have of more or less "official" ENUM or=20 > ENUM trial > >> related Web Sites etc. > >> If anyone has others pass them along. > >> The ENUM Forum in the United States > >> http://www.enum-forum.org/ > >> ENUM in Austria > >> http://www.rtr.at/web.nsf/englisch/=20 > >> Telekommunikation~Nummerierung~ENUM?OpenDocument ENUM in the UK > >> http://www.dti.gov.uk/cii/regulatory/enum/egp_report.shtml > >> http://www.dti.gov.uk/cii/regulatory/enum/ukeg20021108.ppt > >> ENUM in France > >> http://www.numerobis.prd.fr/welcome.shtml > >> ENUM in Australia > >> http://www.aca.gov.au/committee/nsg2/enum.htm > >> ENUM in The Netherlands > >> http://www.enuminnederland.nl > >> ENUM in China > >> http://www.enum.cn/index-en.html > >> ENUM in Germany > >> http://www.denic.de/enum/index.html > >> ENUM in Switzerland > >> http://www.ofcom.ch/en/telekommunikation/nummerierung/enum/ > >> ENUM in Korea > >> http://www.enum.or.kr/ > >> In addition considerable information on the current status=20 > of ENUM =20 > >> can be found at the ITU-T's web site > >> http://www.itu.int/ITU-T/inr/enum/index.html > >> and also at RIPE NCC's web site > >> http://www.ripe.net/enum/ > >> Some information on trials is at > >> http://www.itu.int/ITU-T/inr/enum/trials.html > >> This seems to be a list of current delegations in=20 > e164.arpa I cant =20 > >> testify to its accuracy and there is no indication of when=20 > the page =20 > >> was updated. > >> http://www.enum.info/ENUM%20Matrix.htm > >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> Richard Shockey, Senior Manager, Strategic Technology Initiatives > >> NeuStar Inc. > >> 46000 Center Oak Plaza - Sterling, VA 20166 > >> Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > >> or > >> ; > >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >> _______________________________________________ > >> enum mailing list > >> enum@ietf.org > >> https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 03:19:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01230 for ; Tue, 1 Jul 2003 03:19:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h617J3Y13493 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 03:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFPp-0003UF-TN; Tue, 01 Jul 2003 03:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFP6-0003QG-Q6 for enum@optimus.ietf.org; Tue, 01 Jul 2003 03:18:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01180 for ; Tue, 1 Jul 2003 03:18:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XFOx-0000S6-00 for enum@ietf.org; Tue, 01 Jul 2003 03:18:07 -0400 Received: from smtp10.atl.mindspring.net ([207.69.200.246]) by ietf-mx with esmtp (Exim 4.12) id 19XFOc-0000Qm-00 for enum@ietf.org; Tue, 01 Jul 2003 03:17:46 -0400 Received: from dialup-67.30.22.188.dial1.dallas1.level3.net ([67.30.22.188] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 19XFN8-0000Jf-00; Tue, 01 Jul 2003 03:16:14 -0400 Message-ID: <3F015080.5CECE6E7@ix.netcom.com> Date: Tue, 01 Jul 2003 02:12:33 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Patrik Fältström" CC: "McCandless, Kevin" , "'Richard Shockey'" , enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt References: <417E15D0-AB8D-11D7-BE0E-000A959CF516@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA01181 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Patrik and all, Unless I am missing something here Patrik your argument seems to be circular below.???? Patrik F=E4ltstr=F6m wrote: > On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm, McCandless, Kevin > wrote: > > > So, is DNSSEC within the scope of our discussions or not. During the > > last IETF meeting I thought I heard that DNSSEC is out of scope. My > > opinion is that DNSSEC is relevant when security issues are discussed > > for ENUM. > > I think I argued against DNSSEC, and I will still do it. > > Reasons are: > > - This wg is _not_ where DNSSEC specification is discussed, > this wg is using the DNS protocol > - DNSSEC development is behind ENUM, which means we can not > have a mandatory to implement DNSSEC, as DNSSEC doesn't > exists (or rather, doesn't work as specified) > > If we talk too much about DNSSEC, I am extremely nervous we dive into > trying to solve all problems with DNSSEC the DNS wg's are working with. > > That said, YES, it is _extremely_important_ we get some way of > verifying DNS records we get back when querying the DNS. Both for ENUM > and other applications. > > I take for granted _all_ users of DNS will start using DNSSEC as soon > as it is possible. > > ENUM is not an exception. > > paf > > > > > Kevin... > > > >> -----Original Message----- > >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] > >> Sent: Monday, June 30, 2003 8:55 AM > >> To: enum@ietf.org > >> Subject: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > >> > >> > >> > >> FYI > >> > >> > >> A useful document to keep in mind considering our ongoing > >> discussions of > >> DNSSEC. > >> > >>> To: IETF-Announce: ; > >>> Cc: namedroppers@ops.ietf.org > >>> From: Internet-Drafts@ietf.org > >>> Reply-to: Internet-Drafts@ietf.org > >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 > >>> Sender: owner-ietf-announce@ietf.org > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> This draft is a work item of the DNS Extensions Working > >> Group of the IETF. > >>> > >>> Title : Threat Analysis Of The Domain Name System > >>> Author(s) : D. Atkins, R. Austein > >>> Filename : draft-ietf-dnsext-dns-threats-03.txt > >>> Pages : 15 > >>> Date : 2003-6-27 > >>> > >>> Although the DNS Security Extensions (DNSSEC) have been under > >>> development for most of the last decade, the IETF has never written > >>> down the specific set of threats against which DNSSEC is designed t= o > >>> protect. Among other drawbacks, this cart-before-the-horse situati= on > >>> has made it difficult to determine whether DNSSEC meets its design > >>> goals, since its design goals are not well specified. This note > >>> attempts to document some of the known threats to the DNS, and, in > >>> doing so, attempts to measure to what extent (if any) DNSSEC is a > >>> useful tool in defending against these threats. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > > eats-03.txt > >> > >> To remove yourself from the IETF Announcement list, send a message t= o > >> ietf-announce-request with the word unsubscribe in the body of the > >> message. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username > >> "anonymous" and a password of your e-mail address. After logging in, > >> type "cd internet-drafts" and then > >> "get draft-ietf-dnsext-dns-threats-03.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". > >> > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE= " > >> command. To decode the response(s), you will need "munpack" > >> or > >> a MIME-compliant mail reader. Different MIME-compliant mail > >> readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been > >> split > >> up into multiple messages), so check your local documentatio= n > >> on > >> how to manipulate these messages. > >> > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> Content-Type: text/plain > >> Content-ID: <2003-6-27150122.I-D@ietf.org> > >> > >> ENCODING mime > >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt > >> > >> >> 03.txt> > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > > or > > > > ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 03:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01735 for ; Tue, 1 Jul 2003 03:41:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h617fGn19365 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 03:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFl8-0004xt-Pt; Tue, 01 Jul 2003 03:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XFl0-0004vQ-AZ for enum@optimus.ietf.org; Tue, 01 Jul 2003 03:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01724 for ; Tue, 1 Jul 2003 03:40:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XFkr-0000af-00 for enum@ietf.org; Tue, 01 Jul 2003 03:40:45 -0400 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 19XFkQ-0000aS-00 for enum@ietf.org; Tue, 01 Jul 2003 03:40:19 -0400 Received: from dialup-67.30.2.62.dial1.dallas1.level3.net ([67.30.2.62] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19XFjl-0003IM-00; Tue, 01 Jul 2003 03:39:37 -0400 Message-ID: <3F0155FA.1EBEFADA@ix.netcom.com> Date: Tue, 01 Jul 2003 02:35:55 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: "Patrik Fältström" , "McCandless, Kevin" , Richard Shockey , enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt References: <06CF906FE3998C4E944213062009F1620E9FA0@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA01725 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard and all, I did not gather from Patrik's comments/argument the conclusion you seem to have Richard. However I agree that the DNSSEC WG needs to get busy and work on a solution that is workable for ENUM. This would of course show clearly that DNSSEC and any final call on ENUM are irrevocably linked... Ergo "In scope"... Stastny Richard wrote: > I fully agree with Patrik. > > IMHO dnssec should come up with a solution workable for all existing > DNS applications and ENUM is one of them. > > So it is up to dnsext to solve the problem and enum WG may help if > required (requested). > > Richard > > > -----Original Message----- > > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > > Sent: Tuesday, July 01, 2003 8:29 AM > > To: McCandless, Kevin > > Cc: 'Richard Shockey'; enum@ietf.org > > Subject: Re: [Enum] Fwd: I-D > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > > > On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm, > > McCandless, Kevin > > wrote: > > > > > So, is DNSSEC within the scope of our discussions or not. > > During the > > > last IETF meeting I thought I heard that DNSSEC is out of > > scope. My > > > opinion is that DNSSEC is relevant when security issues are > > discussed > > > for ENUM. > > > > I think I argued against DNSSEC, and I will still do it. > > > > Reasons are: > > > > - This wg is _not_ where DNSSEC specification is discussed, > > this wg is using the DNS protocol > > - DNSSEC development is behind ENUM, which means we can not > > have a mandatory to implement DNSSEC, as DNSSEC doesn't > > exists (or rather, doesn't work as specified) > > > > If we talk too much about DNSSEC, I am extremely nervous we > > dive into > > trying to solve all problems with DNSSEC the DNS wg's are > > working with. > > > > That said, YES, it is _extremely_important_ we get some way of > > verifying DNS records we get back when querying the DNS. Both > > for ENUM > > and other applications. > > > > I take for granted _all_ users of DNS will start using DNSSEC > > as soon > > as it is possible. > > > > ENUM is not an exception. > > > > paf > > > > > > > > > > Kevin... > > > > > >> -----Original Message----- > > >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] > > >> Sent: Monday, June 30, 2003 8:55 AM > > >> To: enum@ietf.org > > >> Subject: [Enum] Fwd: I-D > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > >> > > >> > > >> > > >> FYI > > >> > > >> > > >> A useful document to keep in mind considering our ongoing > > discussions > > >> of DNSSEC. > > >> > > >>> To: IETF-Announce: ; > > >>> Cc: namedroppers@ops.ietf.org > > >>> From: Internet-Drafts@ietf.org > > >>> Reply-to: Internet-Drafts@ietf.org > > >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > > >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 > > >>> Sender: owner-ietf-announce@ietf.org > > >>> > > >>> > > >>> A New Internet-Draft is available from the on-line > > Internet-Drafts > > >>> directories. This draft is a work item of the DNS > > Extensions Working > > >> Group of the IETF. > > >>> > > >>> Title : Threat Analysis Of The Domain > > Name System > > >>> Author(s) : D. Atkins, R. Austein > > >>> Filename : draft-ietf-dnsext-dns-threats-03.txt > > >>> Pages : 15 > > >>> Date : 2003-6-27 > > >>> > > >>> Although the DNS Security Extensions (DNSSEC) have been under > > >>> development for most of the last decade, the IETF has > > never written > > >>> down the specific set of threats against which DNSSEC is > > designed to > > >>> protect. Among other drawbacks, this cart-before-the-horse > > >>> situation has made it difficult to determine whether DNSSEC meets > > >>> its design goals, since its design goals are not well specified. > > >>> This note attempts to document some of the known threats > > to the DNS, > > >>> and, in doing so, attempts to measure to what extent (if > > any) DNSSEC > > >>> is a useful tool in defending against these threats. > > >>> > > >>> A URL for this Internet-Draft is: > > >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > > > eats-03.txt > > >> > > >> To remove yourself from the IETF Announcement list, send a > > message to > > >> ietf-announce-request with the word unsubscribe in the body of the > > >> message. > > >> > > >> Internet-Drafts are also available by anonymous FTP. Login with th= e > > >> username > > >> "anonymous" and a password of your e-mail address. After > > logging in, > > >> type "cd internet-drafts" and then > > >> "get draft-ietf-dnsext-dns-threats-03.txt". > > >> > > >> A list of Internet-Drafts directories can be found in > > >> http://www.ietf.org/shadow.html or > > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > >> > > >> Internet-Drafts can also be obtained by e-mail. > > >> > > >> Send a message to: > > >> mailserv@ietf.org. > > >> In the body type: > > >> "FILE > > /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". > > >> > > >> NOTE: The mail server at ietf.org can return the document in > > >> MIME-encoded form by using the "mpack" utility. > > To use this > > >> feature, insert the command "ENCODING mime" before > > the "FILE" > > >> command. To decode the response(s), you will need > > "munpack" > > >> or > > >> a MIME-compliant mail reader. Different > > MIME-compliant mail > > >> readers > > >> exhibit different behavior, especially when dealing with > > >> "multipart" MIME messages (i.e. documents which have been > > >> split > > >> up into multiple messages), so check your local > > documentation > > >> on > > >> how to manipulate these messages. > > >> > > >> > > >> Below is the data which will enable a MIME compliant mail reader > > >> implementation to automatically retrieve the ASCII version of the > > >> Internet-Draft. > > >> Content-Type: text/plain > > >> Content-ID: <2003-6-27150122.I-D@ietf.org> > > >> > > >> ENCODING mime > > >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt > > >> > > >> > >> 03.txt> > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > > NeuStar Inc. > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > > > or > > > > > > ; > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 04:24:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02697 for ; Tue, 1 Jul 2003 04:24:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h618OGL27397 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 04:24:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGQk-00071m-CN; Tue, 01 Jul 2003 04:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGQJ-00071H-AF for enum@optimus.ietf.org; Tue, 01 Jul 2003 04:23:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02648 for ; Tue, 1 Jul 2003 04:23:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XGQE-0000wV-00 for enum@ietf.org; Tue, 01 Jul 2003 04:23:30 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19XGPv-0000w3-00 for enum@ietf.org; Tue, 01 Jul 2003 04:23:12 -0400 Content-Class: urn:content-classes:message Subject: RE: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jul 2003 10:26:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620E9FA1@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Thread-Index: AcM/pJIrI2YrbmexRxK3gFhtFG+CggABNfyA From: "Stastny Richard" To: "Jeff Williams" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "McCandless, Kevin" , "Richard Shockey" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I completely disagree to >This would=20 > of course show clearly that DNSSEC and any final call on ENUM=20 > are irrevocably linked... Ergo "In scope"... This would mean that any final call of an RFC is irrevocably linked to all other potential RFCs having a problem and also to world hunger to be = solved. Richard > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com]=20 > Sent: Tuesday, July 01, 2003 11:36 AM > To: Stastny Richard > Cc: Patrik F=E4ltstr=F6m; McCandless, Kevin; Richard Shockey;=20 > enum@ietf.org > Subject: Re: [Enum] Fwd: I-D=20 > ACTION:draft-ietf-dnsext-dns-threats-03.txt >=20 >=20 > Richard and all, >=20 > I did not gather from Patrik's comments/argument the=20 > conclusion you seem to have Richard. >=20 > However I agree that the DNSSEC WG needs to get busy > and work on a solution that is workable for ENUM. This would=20 > of course show clearly that DNSSEC and any final call on ENUM=20 > are irrevocably linked... Ergo "In scope"... >=20 > Stastny Richard wrote: >=20 > > I fully agree with Patrik. > > > > IMHO dnssec should come up with a solution workable for all=20 > existing=20 > > DNS applications and ENUM is one of them. > > > > So it is up to dnsext to solve the problem and enum WG may help if=20 > > required (requested). > > > > Richard > > > > > -----Original Message----- > > > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > > > Sent: Tuesday, July 01, 2003 8:29 AM > > > To: McCandless, Kevin > > > Cc: 'Richard Shockey'; enum@ietf.org > > > Subject: Re: [Enum] Fwd: I-D=20 > > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > > > > > > On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm, McCandless,=20 > > > Kevin > > > wrote: > > > > > > > So, is DNSSEC within the scope of our discussions or not. > > > During the > > > > last IETF meeting I thought I heard that DNSSEC is out of > > > scope. My > > > > opinion is that DNSSEC is relevant when security issues are > > > discussed > > > > for ENUM. > > > > > > I think I argued against DNSSEC, and I will still do it. > > > > > > Reasons are: > > > > > > - This wg is _not_ where DNSSEC specification is discussed, > > > this wg is using the DNS protocol > > > - DNSSEC development is behind ENUM, which means we can not > > > have a mandatory to implement DNSSEC, as DNSSEC doesn't > > > exists (or rather, doesn't work as specified) > > > > > > If we talk too much about DNSSEC, I am extremely nervous we dive=20 > > > into trying to solve all problems with DNSSEC the DNS wg's are > > > working with. > > > > > > That said, YES, it is _extremely_important_ we get some way of=20 > > > verifying DNS records we get back when querying the DNS. Both for=20 > > > ENUM and other applications. > > > > > > I take for granted _all_ users of DNS will start using DNSSEC as=20 > > > soon as it is possible. > > > > > > ENUM is not an exception. > > > > > > paf > > > > > > > > > > > > > > Kevin... > > > > > > > >> -----Original Message----- > > > >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] > > > >> Sent: Monday, June 30, 2003 8:55 AM > > > >> To: enum@ietf.org > > > >> Subject: [Enum] Fwd: I-D > > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > >> > > > >> > > > >> > > > >> FYI > > > >> > > > >> > > > >> A useful document to keep in mind considering our ongoing > > > discussions > > > >> of DNSSEC. > > > >> > > > >>> To: IETF-Announce: ; > > > >>> Cc: namedroppers@ops.ietf.org > > > >>> From: Internet-Drafts@ietf.org > > > >>> Reply-to: Internet-Drafts@ietf.org > > > >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 > > > >>> Sender: owner-ietf-announce@ietf.org > > > >>> > > > >>> > > > >>> A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > >>> directories. This draft is a work item of the DNS > > > Extensions Working > > > >> Group of the IETF. > > > >>> > > > >>> Title : Threat Analysis Of The Domain > > > Name System > > > >>> Author(s) : D. Atkins, R. Austein > > > >>> Filename : draft-ietf-dnsext-dns-threats-03.txt > > > >>> Pages : 15 > > > >>> Date : 2003-6-27 > > > >>> > > > >>> Although the DNS Security Extensions (DNSSEC) have been under=20 > > > >>> development for most of the last decade, the IETF has > > > never written > > > >>> down the specific set of threats against which DNSSEC is > > > designed to > > > >>> protect. Among other drawbacks, this cart-before-the-horse=20 > > > >>> situation has made it difficult to determine whether DNSSEC=20 > > > >>> meets its design goals, since its design goals are not well=20 > > > >>> specified. This note attempts to document some of the known=20 > > > >>> threats > > > to the DNS, > > > >>> and, in doing so, attempts to measure to what extent (if > > > any) DNSSEC > > > >>> is a useful tool in defending against these threats. > > > >>> > > > >>> A URL for this Internet-Draft is:=20 > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > > > > eats-03.txt > > > >> > > > >> To remove yourself from the IETF Announcement list, send a > > > message to > > > >> ietf-announce-request with the word unsubscribe in the body of=20 > > > >> the message. > > > >> > > > >> Internet-Drafts are also available by anonymous FTP.=20 > Login with=20 > > > >> the username "anonymous" and a password of your e-mail=20 > address.=20 > > > >> After > > > logging in, > > > >> type "cd internet-drafts" and then > > > >> "get draft-ietf-dnsext-dns-threats-03.txt". > > > >> > > > >> A list of Internet-Drafts directories can be found in=20 > > > >> http://www.ietf.org/shadow.html or=20 > > > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >> > > > >> > > > >> Internet-Drafts can also be obtained by e-mail. > > > >> > > > >> Send a message to: > > > >> mailserv@ietf.org. > > > >> In the body type: > > > >> "FILE > > > /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". > > > >> > > > >> NOTE: The mail server at ietf.org can return the document in > > > >> MIME-encoded form by using the "mpack" utility. > > > To use this > > > >> feature, insert the command "ENCODING mime" before > > > the "FILE" > > > >> command. To decode the response(s), you will need > > > "munpack" > > > >> or > > > >> a MIME-compliant mail reader. Different > > > MIME-compliant mail > > > >> readers > > > >> exhibit different behavior, especially when=20 > dealing with > > > >> "multipart" MIME messages (i.e. documents=20 > which have been=20 > > > >> split > > > >> up into multiple messages), so check your local > > > documentation > > > >> on > > > >> how to manipulate these messages. > > > >> > > > >> > > > >> Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > >> implementation to automatically retrieve the ASCII=20 > version of the=20 > > > >> Internet-Draft. > > > >> Content-Type: text/plain > > > >> Content-ID: <2003-6-27150122.I-D@ietf.org> > > > >> > > > >> ENCODING mime > > > >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt > > > >> > > > >>=20 > > >> - > > >> 03.txt> > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Richard Shockey, Senior Manager, Strategic Technology Initiatives=20 > > > NeuStar Inc. > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1=20 > > > 815.333.1237 or=20 > > > > > > ; =20 > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) = "Be precise in the use of words and expect precision from others" - Pierre Abelard = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CEO/DIR. Internet Network Eng. SR. Eng. Network data security = Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com = Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 05:47:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04555 for ; Tue, 1 Jul 2003 05:47:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h619l6R08663 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 05:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XHj3-0002FH-98; Tue, 01 Jul 2003 05:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XHiu-0002Et-6F for enum@optimus.ietf.org; Tue, 01 Jul 2003 05:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04541 for ; Tue, 1 Jul 2003 05:46:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XHio-0001d0-00 for enum@ietf.org; Tue, 01 Jul 2003 05:46:46 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19XHie-0001cZ-00 for enum@ietf.org; Tue, 01 Jul 2003 05:46:36 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 10:45:36 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCACH0; Tue, 1 Jul 2003 10:45:30 +0100 From: "Conroy, Lawrence (SMTP)" To: Stastny Richard , Jeff Williams Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <06CF906FE3998C4E944213062009F1620E9FA1@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620E9FA1@oefeg-s02.oefeg.loc> Date: Tue, 1 Jul 2003 10:45:24 +0100 Subject: RE: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:26 am +0200 1/7/03, Stastny Richard wrote: >I completely disagree to > >>This would >> of course show clearly that DNSSEC and any final call on ENUM >> are irrevocably linked... Ergo "In scope"... > >This would mean that any final call of an RFC is irrevocably linked to >all other potential RFCs having a problem and also to world hunger >to be solved. > >Richard Hi Folks, Solving world hunger might be quicker. The trite answer is that, given that there are trials are registrations already, ENUM certainly does work without DNSSEC implementation, so it isn't dependent on a fully implemented DNSSEC infrastructure. The reasonable answer (looking at our charter) is that, when there's a view of the implications of DNSSEC ->roll-out<- on the ENUM system, it is a perfectly valid thing to discuss these implications on the way that ENUM is used. Note that these discussions would cover the technical impacts. It need NOT cover the Administration/Social issues like who signs what and who is allowed to sign what, under whose authority, who is responsible for all this, and what is the legal framework, all of which IMHO we can safely leave to the experts :). Seems to me we have a wild agreement going on in this thread. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 13:47:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08053 for ; Tue, 1 Jul 2003 13:47:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIahd12024 for enum-archive@odin.ietf.org; Fri, 27 Jun 2003 14:36:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy3F-00022W-C3; Fri, 27 Jun 2003 14:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvtA-0007Ys-AL for enum@optimus.ietf.org; Fri, 27 Jun 2003 12:15:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05933 for ; Fri, 27 Jun 2003 12:15:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vvst-0004G9-00 for enum@ietf.org; Fri, 27 Jun 2003 12:15:35 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19Vvsj-0004FV-00 for enum@ietf.org; Fri, 27 Jun 2003 12:15:25 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h5RGDxe08614 for ; Fri, 27 Jun 2003 16:13:59 GMT Message-Id: <5.2.0.9.2.20030627112825.04e7deb8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 11:30:25 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Document actions.... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Last call on draft-ietf-enum-sip-00.txt is now concluded. Last call on draft-ietf-enum-webft-00.txt draft-ietf-enum-msg-00.txt will conclude Wed July 2 at 12 Noon EST >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 13:47:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08122 for ; Tue, 1 Jul 2003 13:47:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIah412027 for enum-archive@odin.ietf.org; Fri, 27 Jun 2003 14:36:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy3F-00022r-Q3; Fri, 27 Jun 2003 14:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VvtF-0007Z5-28 for enum@optimus.ietf.org; Fri, 27 Jun 2003 12:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05937; Fri, 27 Jun 2003 12:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VvtD-0004GF-00; Fri, 27 Jun 2003 12:15:55 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19Vvt2-0004G6-00; Fri, 27 Jun 2003 12:15:44 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h5RGF9e08660; Fri, 27 Jun 2003 16:15:09 GMT Message-Id: <5.2.0.9.2.20030627105830.033ea320@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 12:11:27 -0400 To: iesg-secretary@ietf.org From: Richard Shockey Cc: mankin@psg.com, jon.peterson@neustar.biz, paf@cisco.com, enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Request to Publish - draft-ietf-enum-sip-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a formal request publication by the IETF ENUM WG working group for one document. The document below is being proposed for consideration as Standards Track RFC. Status - Proposed Standard This is a working group product, which has been discussed during 2002-2003 and WG last call on this document concluded on June 27 Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-ietf-enum-sip-00.txt Pages : 9 Date : 2003-2-26 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 13:48:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08388 for ; Tue, 1 Jul 2003 13:48:14 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UDoxF01180 for enum-archive@odin.ietf.org; Mon, 30 Jun 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wz2f-000079-Qj; Mon, 30 Jun 2003 09:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wz1p-00006Q-RS for enum@optimus.ietf.org; Mon, 30 Jun 2003 09:49:09 -0400 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23892 for ; Mon, 30 Jun 2003 09:48:52 -0400 (EDT) Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h5UDm1c16430 for ; Mon, 30 Jun 2003 13:48:01 GMT Message-Id: <5.2.0.9.2.20030626105154.0331f6d0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Jun 2003 09:44:35 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Enum] Draft Agenda ENUM WG IETF 57 Vienna Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Comments folks? MONDAY, July 14, 2003 1130-1300 Break 1300-1500 Afternoon Sessions I Hall LM APP xmpp Extensible Messaging and Presence Protocol WG Hall F2 GEN coach Comprehensive apprOACH to quality BOF Hall E2 INT pana Protocol for carrying Authentication for Network Access WG Hall F1 OPS multi6 Site Multihoming in IPv6 WG Hall NO RTG forces Forwarding and Control Element Separation WG Hall GH SUB tewg Internet Traffic Engineering WG Hall IK TSV enum Telephone Number Mapping WG IETF 57 Vienna Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction =85 VOLUNTEERS WANTED ! or Else ... . 1. Applicability Statement of CRISP work to ENUM - 20 Min Title : IRIS - An ENUM Registry (ereg) Type for the=20 Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-00.txt Pages : 34 Date : 2003-6-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt 2. Security and Privacy Considerations Shockey - Morris 20 min Draft URL TBD ... 3. Review of National ENUM Trials ... UK - Austria - Korea 10 Min or= suchEach 4. WG next steps 20 Min + Jim Reid etal. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 13:48:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08331 for ; Tue, 1 Jul 2003 13:48:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UDoxr01181 for enum-archive@odin.ietf.org; Mon, 30 Jun 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wz2g-00007H-9J; Mon, 30 Jun 2003 09:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wz2L-00006c-57 for enum@optimus.ietf.org; Mon, 30 Jun 2003 09:49:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23982 for ; Mon, 30 Jun 2003 09:49:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wz23-0000jb-00 for enum@ietf.org; Mon, 30 Jun 2003 09:49:23 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19Wz1p-0000i4-00 for enum@ietf.org; Mon, 30 Jun 2003 09:49:10 -0400 Received: from rshockeybox.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5UDpUF15118; Mon, 30 Jun 2003 06:51:30 -0700 Message-Id: <5.2.0.9.2.20030630082432.05254ac0@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Jun 2003 08:28:54 -0400 To: enum@ietf.org From: Richard Shockey Subject: [Enum] ENUM Working Last Call H.323 enumservice registration Cc: paf@cisco.com, mankin@psg.com, jon.peterson@neustar.biz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a formal request for final comments within the IETF ENUM WG working group for one documents. The document listed below is being proposed for forwarding on to the IESG for consideration as Standards Track RFC Standard. This document is a working group product, which has been discussed during 2002-2003. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. The 2 week Last Call will begin immediately and due to the upcoming IETF meetings will end on July 22 at 12PM EST . Title : ENUM Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-ietf-enum-h323-01.txt Pages : 4 Date : 2003-6-27 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 15:31:31 2003 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 PAA13728 for ; Tue, 1 Jul 2003 15:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQqE-0003cn-Mz for enum-archive@odin.ietf.org; Tue, 01 Jul 2003 15:31:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h61JV2dE013895 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 15:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQlb-0003Qy-AR; Tue, 01 Jul 2003 15:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQkQ-0003P7-D1 for enum@optimus.ietf.org; Tue, 01 Jul 2003 15:25:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10029 for ; Tue, 1 Jul 2003 14:28:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XPrj-0006sm-00 for enum@ietf.org; Tue, 01 Jul 2003 14:28:31 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19XPrj-0006ql-00 for enum@ietf.org; Tue, 01 Jul 2003 14:28:31 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h61IRpc11681 for ; Tue, 1 Jul 2003 18:27:51 GMT Message-Id: <5.2.0.9.2.20030701142449.03284f38@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Jul 2003 14:28:34 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] List of ENUM servicefields in process... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI > E2U+H323 "h323:" URI > E2U+SIP "sip:" URI > E2U+web:http "http:" URI > E2U+web:https "https:" URI > E2U+ft:ftp "ftp:" URI FTP file > transfer > > E2U+fax:tel "tel:" URI T.30 POTS fax > > E2U+email:mailto "mailto:" URI > E2U+sms:tel "tel:" URI > E2U+ems:tel "tel:" URI > E2U+mms:tel "tel:" URI > E2U+email:mailto "mailto:" URI in process for approval from other WG's E2U+ifax:smtp "mailto:" URI from the Internet Fax WG E2U+VPIM:mailto "mailto:" URI from the VPIM Voice Profile for Internet Mail In process but not ready yet. > E2U+pres "pres:" URI for Presence >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 1 22:07:58 2003 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 WAA24791 for ; Tue, 1 Jul 2003 22:07:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX1p-0001fT-4F for enum-archive@odin.ietf.org; Tue, 01 Jul 2003 22:07:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6227Prw006407 for enum-archive@odin.ietf.org; Tue, 1 Jul 2003 22:07:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX1R-0001UL-VE; Tue, 01 Jul 2003 22:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX11-0001T5-S7 for enum@optimus.ietf.org; Tue, 01 Jul 2003 22:06:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24772 for ; Tue, 1 Jul 2003 22:06:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XX0y-0004Ga-00 for enum@ietf.org; Tue, 01 Jul 2003 22:06:32 -0400 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 19XX0x-0004GX-00 for enum@ietf.org; Tue, 01 Jul 2003 22:06:31 -0400 Received: from dialup-67.30.2.125.dial1.dallas1.level3.net ([67.30.2.125] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19XX0g-0005do-00; Tue, 01 Jul 2003 22:06:14 -0400 Message-ID: <3F025959.DC994AF5@ix.netcom.com> Date: Tue, 01 Jul 2003 21:02:34 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: "Patrik Fältström" , "McCandless, Kevin" , Richard Shockey , enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt References: <06CF906FE3998C4E944213062009F1620E9FA1@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA24773 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard and all, I understood that you disagreed already Richard. However I think your arguments, most especially the brief one below making a outrageous comparison to world hunger is very much divisive rather than constructive. DNSSEC is definitely "IN Scope" and linked to ENUM as has already been made apparent... Stastny Richard wrote: > I completely disagree to > > >This would > > of course show clearly that DNSSEC and any final call on ENUM > > are irrevocably linked... Ergo "In scope"... > > This would mean that any final call of an RFC is irrevocably linked to > all other potential RFCs having a problem and also to world hunger to b= e solved. > > Richard > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Tuesday, July 01, 2003 11:36 AM > > To: Stastny Richard > > Cc: Patrik F=E4ltstr=F6m; McCandless, Kevin; Richard Shockey; > > enum@ietf.org > > Subject: Re: [Enum] Fwd: I-D > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > > > Richard and all, > > > > I did not gather from Patrik's comments/argument the > > conclusion you seem to have Richard. > > > > However I agree that the DNSSEC WG needs to get busy > > and work on a solution that is workable for ENUM. This would > > of course show clearly that DNSSEC and any final call on ENUM > > are irrevocably linked... Ergo "In scope"... > > > > Stastny Richard wrote: > > > > > I fully agree with Patrik. > > > > > > IMHO dnssec should come up with a solution workable for all > > existing > > > DNS applications and ENUM is one of them. > > > > > > So it is up to dnsext to solve the problem and enum WG may help if > > > required (requested). > > > > > > Richard > > > > > > > -----Original Message----- > > > > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > > > > Sent: Tuesday, July 01, 2003 8:29 AM > > > > To: McCandless, Kevin > > > > Cc: 'Richard Shockey'; enum@ietf.org > > > > Subject: Re: [Enum] Fwd: I-D > > > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > > > > > > > > > On m=E5ndag, jun 30, 2003, at 16:23 Europe/Stockholm, McCandless, > > > > Kevin > > > > wrote: > > > > > > > > > So, is DNSSEC within the scope of our discussions or not. > > > > During the > > > > > last IETF meeting I thought I heard that DNSSEC is out of > > > > scope. My > > > > > opinion is that DNSSEC is relevant when security issues are > > > > discussed > > > > > for ENUM. > > > > > > > > I think I argued against DNSSEC, and I will still do it. > > > > > > > > Reasons are: > > > > > > > > - This wg is _not_ where DNSSEC specification is discussed, > > > > this wg is using the DNS protocol > > > > - DNSSEC development is behind ENUM, which means we can not > > > > have a mandatory to implement DNSSEC, as DNSSEC doesn't > > > > exists (or rather, doesn't work as specified) > > > > > > > > If we talk too much about DNSSEC, I am extremely nervous we dive > > > > into trying to solve all problems with DNSSEC the DNS wg's are > > > > working with. > > > > > > > > That said, YES, it is _extremely_important_ we get some way of > > > > verifying DNS records we get back when querying the DNS. Both for > > > > ENUM and other applications. > > > > > > > > I take for granted _all_ users of DNS will start using DNSSEC as > > > > soon as it is possible. > > > > > > > > ENUM is not an exception. > > > > > > > > paf > > > > > > > > > > > > > > > > > > Kevin... > > > > > > > > > >> -----Original Message----- > > > > >> From: Richard Shockey [mailto:rich.shockey@neustar.biz] > > > > >> Sent: Monday, June 30, 2003 8:55 AM > > > > >> To: enum@ietf.org > > > > >> Subject: [Enum] Fwd: I-D > > > > ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > >> > > > > >> > > > > >> > > > > >> FYI > > > > >> > > > > >> > > > > >> A useful document to keep in mind considering our ongoing > > > > discussions > > > > >> of DNSSEC. > > > > >> > > > > >>> To: IETF-Announce: ; > > > > >>> Cc: namedroppers@ops.ietf.org > > > > >>> From: Internet-Drafts@ietf.org > > > > >>> Reply-to: Internet-Drafts@ietf.org > > > > >>> Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt > > > > >>> Date: Mon, 30 Jun 2003 07:37:45 -0400 > > > > >>> Sender: owner-ietf-announce@ietf.org > > > > >>> > > > > >>> > > > > >>> A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > >>> directories. This draft is a work item of the DNS > > > > Extensions Working > > > > >> Group of the IETF. > > > > >>> > > > > >>> Title : Threat Analysis Of The Domain > > > > Name System > > > > >>> Author(s) : D. Atkins, R. Austein > > > > >>> Filename : draft-ietf-dnsext-dns-threats-03.tx= t > > > > >>> Pages : 15 > > > > >>> Date : 2003-6-27 > > > > >>> > > > > >>> Although the DNS Security Extensions (DNSSEC) have been under > > > > >>> development for most of the last decade, the IETF has > > > > never written > > > > >>> down the specific set of threats against which DNSSEC is > > > > designed to > > > > >>> protect. Among other drawbacks, this cart-before-the-horse > > > > >>> situation has made it difficult to determine whether DNSSEC > > > > >>> meets its design goals, since its design goals are not well > > > > >>> specified. This note attempts to document some of the known > > > > >>> threats > > > > to the DNS, > > > > >>> and, in doing so, attempts to measure to what extent (if > > > > any) DNSSEC > > > > >>> is a useful tool in defending against these threats. > > > > >>> > > > > >>> A URL for this Internet-Draft is: > > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-thr > > > > > eats-03.txt > > > > >> > > > > >> To remove yourself from the IETF Announcement list, send a > > > > message to > > > > >> ietf-announce-request with the word unsubscribe in the body of > > > > >> the message. > > > > >> > > > > >> Internet-Drafts are also available by anonymous FTP. > > Login with > > > > >> the username "anonymous" and a password of your e-mail > > address. > > > > >> After > > > > logging in, > > > > >> type "cd internet-drafts" and then > > > > >> "get draft-ietf-dnsext-dns-threats-03.txt". > > > > >> > > > > >> A list of Internet-Drafts directories can be found in > > > > >> http://www.ietf.org/shadow.html or > > > > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > >> > > > > >> > > > > >> Internet-Drafts can also be obtained by e-mail. > > > > >> > > > > >> Send a message to: > > > > >> mailserv@ietf.org. > > > > >> In the body type: > > > > >> "FILE > > > > /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". > > > > >> > > > > >> NOTE: The mail server at ietf.org can return the document in > > > > >> MIME-encoded form by using the "mpack" utility. > > > > To use this > > > > >> feature, insert the command "ENCODING mime" before > > > > the "FILE" > > > > >> command. To decode the response(s), you will need > > > > "munpack" > > > > >> or > > > > >> a MIME-compliant mail reader. Different > > > > MIME-compliant mail > > > > >> readers > > > > >> exhibit different behavior, especially when > > dealing with > > > > >> "multipart" MIME messages (i.e. documents > > which have been > > > > >> split > > > > >> up into multiple messages), so check your local > > > > documentation > > > > >> on > > > > >> how to manipulate these messages. > > > > >> > > > > >> > > > > >> Below is the data which will enable a MIME compliant > > mail reader > > > > >> implementation to automatically retrieve the ASCII > > version of the > > > > >> Internet-Draft. > > > > >> Content-Type: text/plain > > > > >> Content-ID: <2003-6-27150122.I-D@ietf.org> > > > > >> > > > > >> ENCODING mime > > > > >> FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt > > > > >> > > > > >> > > ats > > > >> - > > > >> 03.txt> > > > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > > > NeuStar Inc. > > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 > > > > 815.333.1237 or > > > > > > > > ; > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) = "Be precise in the use of words and expect precision from others" - > Pierre Abelard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CEO/DIR. Internet Network Eng. SR. Eng. Network data security Informati= on Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact N= umber: 214-244-4827 or 214-244-3801 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 10:18:02 2003 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 KAA22827 for ; Wed, 2 Jul 2003 10:18:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiQM-00047w-D8 for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 10:17:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62EHUQ4015846 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 10:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiPs-00046f-TG; Wed, 02 Jul 2003 10:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiPM-00046B-GQ for enum@optimus.ietf.org; Wed, 02 Jul 2003 10:16:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22619 for ; Wed, 2 Jul 2003 10:16:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XiPK-0000G3-00 for enum@ietf.org; Wed, 02 Jul 2003 10:16:26 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19XiPJ-0000FG-00 for enum@ietf.org; Wed, 02 Jul 2003 10:16:25 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 35339137F1D; Wed, 2 Jul 2003 07:15:53 -0700 (PDT) To: "Stastny Richard" Cc: "McCandless, Kevin" , "Richard Shockey" , enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt In-Reply-To: Message from "Stastny Richard" of "Mon, 30 Jun 2003 17:09:06 +0200." <06CF906FE3998C4E944213062009F1622336FB@oefeg-s02.oefeg.loc> Date: Wed, 02 Jul 2003 07:15:53 -0700 Message-ID: <90890.1057155353@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Stastny Richard writes: Richard> Up to now ENUM WG was not dealing with administrative and Richard> management issues in ENUM, this was left to other bodies Richard> like ITU-T, ETSI and the national ENUM fora and Richard> platforms. Richard> If we now start dealing with: >> stuff like signing policies, key management, dealing with >> signed=20 and unsigned NAPTR RRsets, etc -- probably should be >> in the=20 scope of the WG IMO. Richard> we are jumping head-on in the middle of these issues. No, you misunderstand what I said. Legal and policy issues surrounding DNSSEC such as who holds a Tier-1 key, if any, are a National Matter, if I may use ITU jargon in this forum. These are out of scope for us. However technical issues surrounding DNSSEC deployment for e164.arpa are within scope. [If not this WG, who else would consider them?] These issues would presumably include things like a BCP or recommendations on key lengths, SIG expiry times, key rollover procedures, etc, etc. I think the WG could/should also look at the issues which will arise when parts of the e164.arpa tree are and aren't signed. For instance what does it mean if 4.4.e164.arpa is signed and 3.2.1.4.4.e164.arpa isn't (or vice versa) and what implications this has for clients that may or may not be DNSSEC-aware? Are there ENUM-specific considerations here which won't be addressed by the DNSEXT WG's effort? It is these sorts of technical things that I think this WG should look at. They fall between high-level policy stuff which should be handled by ITU or IAB lawyers (maybe) and the low-level DNSSEC protocol grot that goes on in DNSEXT. And isn't there an IAB/IESG reqirement to show how security protocols like DNSSEC apply to the protocols developed by each IETF WG? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 12:20:39 2003 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 MAA29834 for ; Wed, 2 Jul 2003 12:20:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkL6-0004D1-0r for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 12:20:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62GKCD1016163 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 12:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkKw-00048J-Co; Wed, 02 Jul 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkKg-00047H-9u for enum@optimus.ietf.org; Wed, 02 Jul 2003 12:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29749 for ; Wed, 2 Jul 2003 12:19:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkKe-0003Qi-00 for enum@ietf.org; Wed, 02 Jul 2003 12:19:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19XkKd-0003Q0-00 for enum@ietf.org; Wed, 02 Jul 2003 12:19:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2003 18:19:31 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h62GGnNH016189; Wed, 2 Jul 2003 18:17:05 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 18:19:08 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 18:19:08 +0200 Date: Wed, 2 Jul 2003 18:19:06 +0200 Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Stastny Richard" , "McCandless, Kevin" , "Richard Shockey" , enum@ietf.org To: Jim Reid From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <90890.1057155353@shell.nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 02 Jul 2003 16:19:08.0317 (UTC) FILETIME=[AA1384D0:01C340B5] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On onsdag, jul 2, 2003, at 16:15 Europe/Stockholm, Jim Reid wrote: > These issues would presumably include things like a BCP or > recommendations on key lengths, SIG expiry times, key rollover > procedures, etc, etc. I think the WG could/should also look at the > issues which will arise when parts of the e164.arpa tree are and > aren't signed. For instance what does it mean if 4.4.e164.arpa is > signed and 3.2.1.4.4.e164.arpa isn't (or vice versa) and what > implications this has for clients that may or may not be DNSSEC-aware? > Are there ENUM-specific considerations here which won't be addressed > by the DNSEXT WG's effort? I must say this, as I have said "NO" to general DNSSEC discussions. The _technical_ part of these questions most certainly fits within this wg. But, co-chair Richard, I think you and I should discuss with our AD's what they think about the swap from technical to more operational issues discussed in this wg. _I_ personally think they should be discussed, now that the theoretical part is done. Mixing them up is bad. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 13:02:33 2003 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 NAA01565 for ; Wed, 2 Jul 2003 13:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xkzd-0007QR-7y for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 13:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62H25hA028542 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 13:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkzY-0007Pq-Qe; Wed, 02 Jul 2003 13:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XkzK-0007PK-Qw for enum@optimus.ietf.org; Wed, 02 Jul 2003 13:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01546 for ; Wed, 2 Jul 2003 13:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XkzJ-00044s-00 for enum@ietf.org; Wed, 02 Jul 2003 13:01:45 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19XkzI-00044F-00 for enum@ietf.org; Wed, 02 Jul 2003 13:01:44 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h62H0wc07481; Wed, 2 Jul 2003 17:00:58 GMT Message-Id: <5.2.0.9.2.20030702123523.034f86d8@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Jul 2003 12:57:32 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Jim Reid From: Richard Shockey Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Cc: "Stastny Richard" , "McCandless, Kevin" , enum@ietf.org In-Reply-To: References: <90890.1057155353@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 06:19 PM 7/2/2003 +0200, Patrik F=E4ltstr=F6m wrote: >On onsdag, jul 2, 2003, at 16:15 Europe/Stockholm, Jim Reid wrote: > >>These issues would presumably include things like a BCP or >>recommendations on key lengths, SIG expiry times, key rollover >>procedures, etc, etc. I think the WG could/should also look at the >>issues which will arise when parts of the e164.arpa tree are and >>aren't signed. Jim could you describe for me then the operational differences/similarities= =20 between partial signing of the e164.arpa tree and partial signing of the=20 .com tree? I'm sure inquiring minds at Verisign want to know.. :-) I'm=20 not sure I see the difference at all, frankly. >> For instance what does it mean if 4.4.e164.arpa is >>signed and 3.2.1.4.4.e164.arpa isn't (or vice versa) and what >>implications this has for clients that may or may not be DNSSEC-aware? >>Are there ENUM-specific considerations here which won't be addressed >>by the DNSEXT WG's effort? well that is IMHO _the_ question. >I must say this, as I have said "NO" to general DNSSEC discussions. > >The _technical_ part of these questions most certainly fits within this wg. Within limits ... I would say. ENUM is the DNS so the distinction has to be= =20 made between issues that are specific to 2916bis and the general DNS=20 itself. As I read Jim Reid's message I have concerns about what those=20 issues really are. We should not be debating general DNSEXT WG work here ,= =20 however if we can discover specific problems that they need to address then= =20 certainly work on that and provide appropriate guidance to our colleagues . I don't want DNSSEC issues to turn into the kind of religious discussions=20 we see over NAT's on the general IETF list. >But, co-chair Richard, I think you and I should discuss with our AD's what= =20 >they think about the swap from technical to more operational issues=20 >discussed in this wg. Absolutely ... >_I_ personally think they should be discussed, now that the theoretical=20 >part is done. The question is what are the appropriate boundaries... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 14:56:43 2003 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 OAA06205 for ; Wed, 2 Jul 2003 14:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xmm8-0004lr-EN for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 14:56:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62IuG4l018339 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 14:56:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xmlt-0004ir-6m; Wed, 02 Jul 2003 14:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xmlg-0004iI-GE for enum@optimus.ietf.org; Wed, 02 Jul 2003 14:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06164 for ; Wed, 2 Jul 2003 14:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xmlb-0005lk-00 for enum@ietf.org; Wed, 02 Jul 2003 14:55:43 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19Xmla-0005lQ-00 for enum@ietf.org; Wed, 02 Jul 2003 14:55:43 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h62ItBc10206 for ; Wed, 2 Jul 2003 18:55:11 GMT Message-Id: <5.2.0.9.2.20030702144818.03515678@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Jul 2003 14:51:50 -0400 To: enum@ietf.org From: Richard Shockey Subject: [Enum] Draft Agenda ENUM WG IETF 57 Vienna - Final Comments Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Any additional actions items folks? Any scribe volunteers? Or else.. MONDAY, July 14, 2003 1130-1300 Break 1300-1500 Afternoon Sessions I Hall LM APP xmpp Extensible Messaging and Presence Protocol WG Hall F2 GEN coach Comprehensive apprOACH to quality BOF Hall E2 INT pana Protocol for carrying Authentication for Network Access WG Hall F1 OPS multi6 Site Multihoming in IPv6 WG Hall NO RTG forces Forwarding and Control Element Separation WG Hall GH SUB tewg Internet Traffic Engineering WG Hall IK TSV enum Telephone Number Mapping WG IETF 57 Vienna Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction =85 VOLUNTEERS WANTED ! or Else ... . 1. Applicability Statement of CRISP work to ENUM - 20 Min Title : IRIS - An ENUM Registry (ereg) Type for the= Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-00.txt Pages : 34 Date : 2003-6-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt 2. Security and Privacy Considerations Shockey - Morris 20 min Draft URL To be Published ... 3. Review of National ENUM Trials ... UK - Austria - Korea 10 Min or= suchEach 4. WG next steps 20 Min : Jim Reid , Richard Stastny etc. 5. General Discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 16:45:16 2003 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 QAA15608 for ; Wed, 2 Jul 2003 16:45:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoTC-00058d-Np for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 16:44:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Kiom2019751 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 16:44:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoSO-000578-Up; Wed, 02 Jul 2003 16:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoRk-00055c-EY for enum@optimus.ietf.org; Wed, 02 Jul 2003 16:43:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15371 for ; Wed, 2 Jul 2003 16:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoRg-0007fM-00 for enum@ietf.org; Wed, 02 Jul 2003 16:43:16 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19XoRf-0007c4-00 for enum@ietf.org; Wed, 02 Jul 2003 16:43:15 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h62Kgcc13406 for ; Wed, 2 Jul 2003 20:42:38 GMT Message-Id: <5.2.0.9.2.20030702163848.03401008@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Jul 2003 16:39:13 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI >To: IETF-Announce: ; >Cc: sipping@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Wed, 02 Jul 2003 16:33:49 -0400 >Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt >Sender: sipping-admin@ietf.org >X-BeenThere: sipping@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: SIPPING Working Group (applications of SIP) >List-Post: >List-Help: >List-Subscribe: , > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Proposal Investigation >Working Group of the IETF. > > Title : Using ENUM for SIP Applications > Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell > Filename : draft-ietf-sipping-e164-03.txt > Pages : 22 > Date : 2003-7-2 > >Although SIP was one of the primary applications for which ENUM was >created, there is nevertheless a need to define procedures for >integrating ENUM with SIP implementations. This document illustrates >how the two protocols might work in concert, and clarifies the >authoring and processing of ENUM records for SIP applications. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sipping-e164-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sipping-e164-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-2161907.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sipping-e164-03.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 2 20:32:41 2003 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 UAA06213 for ; Wed, 2 Jul 2003 20:32:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xs1E-0005zI-ND for enum-archive@odin.ietf.org; Wed, 02 Jul 2003 20:32:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h630WCrP023012 for enum-archive@odin.ietf.org; Wed, 2 Jul 2003 20:32:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xs13-0005ym-BW; Wed, 02 Jul 2003 20:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xs0g-0005yK-SK for enum@optimus.ietf.org; Wed, 02 Jul 2003 20:31:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06091 for ; Wed, 2 Jul 2003 20:31:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xs0e-0007Hp-00 for enum@ietf.org; Wed, 02 Jul 2003 20:31:36 -0400 Received: from bay3-f39.bay3.hotmail.com ([65.54.169.39] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19Xs0e-0007Gv-00 for enum@ietf.org; Wed, 02 Jul 2003 20:31:36 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Jul 2003 17:31:06 -0700 Received: from 67.74.39.109 by by3fd.bay3.hotmail.msn.com with HTTP; Thu, 03 Jul 2003 00:31:05 GMT X-Originating-IP: [67.74.39.109] X-Originating-Email: [home_pw@msn.com] From: "Peter Williams" To: rich.shockey@neustar.biz, paf@cisco.com, Jim.Reid@nominum.com Cc: Richard.Stastny@oefeg.at, KMcCandless@verisign.com, enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt Date: Wed, 02 Jul 2003 17:31:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2003 00:31:06.0093 (UTC) FILETIME=[640AB1D0:01C340FA] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA06092 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Any signature, from your initial to a VeriSign-branded digital signature=20 signals legal approval. If there is no clear affadavit or representation within the sig= ned=20 writing of what is being approved, one looks to private policy and then public=20 policy statements, for definitions. In the DNS we have no ultimate root, and no ultimate policy authority. Wh= ile US domains are controlled by a quango, and that body could issue rules defining the meaning of signatures on domain records, the=20 meaning of DNS signatures more generally will need to be defined at an operator level. It is arguable whether IETF should be in the business of standardizing types of approvals, and fields wherein these indications can be communicated. First, in the PEM/PKI community, IETF did not come out with honour, in a similar endeavour: the usage model of internet PKI fell to Microsoft to define in the end, to do=20 something technically coherent. Second, in the 1985-period, UN EDIFACT work=20 addressing similar work on defining standard represneations and assurances for=20 signatures in messaging systems, legions of lawyers could then not agree that the definitions had any value, in any of the 137 different legal systems. We got VeriSign started, to the then IETF's dismay, by avoiding the polit= ics of these issues. It was a very conscious, architectural decision. Forms f= or, and definitions of, useful assurances emerged over time, set by those wit= h the power and the actual community to define them. There are ways of positioning and building a business model , while these events occur. But such work does not fall within the remit of IETF meetin= gs. Its for the meeting before and after IETF: invitees only. Peter. >From: Richard Shockey >To: Patrik F=E4ltstr=F6m , Jim Reid=20 > >CC: "Stastny Richard" , "McCandless,=20 >Kevin" , enum@ietf.org >Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.tx= t=20 >Date: Wed, 02 Jul 2003 12:57:32 -0400 > >At 06:19 PM 7/2/2003 +0200, Patrik F=E4ltstr=F6m wrote: > > >>On onsdag, jul 2, 2003, at 16:15 Europe/Stockholm, Jim Reid wrote: >> >>>These issues would presumably include things like a BCP or >>>recommendations on key lengths, SIG expiry times, key rollover >>>procedures, etc, etc. I think the WG could/should also look at the >>>issues which will arise when parts of the e164.arpa tree are and >>>aren't signed. > > > >Jim could you describe for me then the operational differences/similarit= ies=20 >between partial signing of the e164.arpa tree and partial signing of th= e=20 >.com tree? I'm sure inquiring minds at Verisign want to know.. :-) I'= m=20 >not sure I see the difference at all, frankly. > > >>> For instance what does it mean if 4.4.e164.arpa is >>>signed and 3.2.1.4.4.e164.arpa isn't (or vice versa) and what >>>implications this has for clients that may or may not be DNSSEC-aware? >>>Are there ENUM-specific considerations here which won't be addressed >>>by the DNSEXT WG's effort? > >well that is IMHO _the_ question. > > >>I must say this, as I have said "NO" to general DNSSEC discussions. >> >>The _technical_ part of these questions most certainly fits within this= =20 >>wg. > > >Within limits ... I would say. ENUM is the DNS so the distinction has to= be=20 >made between issues that are specific to 2916bis and the general DNS=20 >itself. As I read Jim Reid's message I have concerns about what those=20 >issues really are. We should not be debating general DNSEXT WG work here= ,=20 >however if we can discover specific problems that they need to address t= hen=20 >certainly work on that and provide appropriate guidance to our colleague= s . > >I don't want DNSSEC issues to turn into the kind of religious discussion= s=20 >we see over NAT's on the general IETF list. > > > >>But, co-chair Richard, I think you and I should discuss with our AD's w= hat=20 >>they think about the swap from technical to more operational issues=20 >>discussed in this wg. > >Absolutely ... > > >>_I_ personally think they should be discussed, now that the theoretical= =20 >>part is done. > >The question is what are the appropriate boundaries... > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Senior Manager, Strategic Technology Initiatives >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 > or > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. =20 http://join.msn.com/?page=3Dfeatures/featuredemail _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 3 01:06:48 2003 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 BAA15549 for ; Thu, 3 Jul 2003 01:06:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XwIU-0005aL-Oy for enum-archive@odin.ietf.org; Thu, 03 Jul 2003 01:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6356IN3021455 for enum-archive@odin.ietf.org; Thu, 3 Jul 2003 01:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XwIE-0005Zf-91; Thu, 03 Jul 2003 01:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XwID-0005ZT-16 for enum@optimus.ietf.org; Thu, 03 Jul 2003 01:06:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15545 for ; Thu, 3 Jul 2003 01:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XwIA-0002px-00 for enum@ietf.org; Thu, 03 Jul 2003 01:05:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19XwI9-0002pt-00 for enum@ietf.org; Thu, 03 Jul 2003 01:05:57 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2003 07:05:44 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6353I7M025271; Thu, 3 Jul 2003 07:03:23 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 07:05:21 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jul 2003 07:05:21 +0200 Date: Thu, 3 Jul 2003 07:05:10 +0200 Subject: Re: [Enum] Draft Agenda ENUM WG IETF 57 Vienna - Final Comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org To: Richard Shockey From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5.2.0.9.2.20030702144818.03515678@shockey.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 03 Jul 2003 05:05:21.0802 (UTC) FILETIME=[B4689EA0:01C34120] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On onsdag, jul 2, 2003, at 20:51 Europe/Stockholm, Richard Shockey wrote: > 3. Review of National ENUM Trials ... UK - Austria - Korea 10 Min or > suchEach I can present the trial in Sweden. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 3 06:44:42 2003 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 GAA05548 for ; Thu, 3 Jul 2003 06:44:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y1ZX-0007Lu-S5 for enum-archive@odin.ietf.org; Thu, 03 Jul 2003 06:44:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63AiF1v028263 for enum-archive@odin.ietf.org; Thu, 3 Jul 2003 06:44:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y1ZJ-0007LP-6O; Thu, 03 Jul 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y1YX-0007Ks-ET for enum@optimus.ietf.org; Thu, 03 Jul 2003 06:43:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05534 for ; Thu, 3 Jul 2003 06:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y1YT-00054c-00 for enum@ietf.org; Thu, 03 Jul 2003 06:43:09 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19Y1YS-00054T-00 for enum@ietf.org; Thu, 03 Jul 2003 06:43:08 -0400 content-class: urn:content-classes:message Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jul 2003 12:46:58 +0200 Message-ID: <06CF906FE3998C4E944213062009F162233708@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Thread-Index: AcNA254r+eOjp6UoSGqpPOcGU0Mi1wAaDfmA From: "Stastny Richard" To: "Richard Shockey" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I have some comments and also some serious problems with this draft. General comment: It may be a dogma in the religion of SIP, but SIP is not the center of the world ;-) General comment: what kind of RFC this will be? The good news first: it is nice to hear that "the most widespread application for SIP today is voice", or "the most common application in SIP is telephony" and that "in most cases, these are request for a telephone session (voice communication)" Comment:=20 I am getting a bit tired to be lectured permanently without asking for it that there is two types of SIP URIs (if this is such a problem, then why not put a parameter or create a sipL: URI) and no contact addresses should appear in ENUM. As far as I know from praxis, nobody ever tried to do this. "SIP URIs in ENUM do not convey capability information. SIP has its own methods for negotiating capability information between user agents (see SDP [13], the use of Require/Supported to negotiate extensions in RFC3261, and callee capabilities [11]); providing more limited capability information within ENUM is at best redundant and at worst potentially misleading to SIP's negotiation system. Also, addresses-of-record do not have capabilities (only devices registered under an address-of-record have actual capabilities), and putting contact addresses in ENUM is not recommended." Amen, btw, a tel URI is also an address-of-record (better: a name) and does not convey any cabability information. On the other hand, if an "author" want to put capability information in ENUM, it is his problem Comment:=20 "Only one SIP URI appears in an ENUM record set ..." This is up to the ENUM subscriber, is it necessary for them to read this document? See also section 5. Authoring of NAPTR records Comment: 5.1 "It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip'=20 service field whenever the regexp contains a SIP address-of-record URI." Are we doing commercials in IETF drafts?. If another enumservice with sip URI is registered with IANA the "authors" may use, if not, not. Major problem: 5.2 5.2 Flags in NAPTR RR "Authors of NAPTR records MUST use the terminal "u" flag when 'E2U+sip' is specified as a Service field." Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA registration. Major problem: 5.3 "Authors of records intended to be used for SIP applications SHOULD always use a greedy regexp; no use-cases have been identified today in which a different antecedent is necessary." I strongly object this. First, the use of regular expessions is a feature in ENUM and DDDS, second, there are use cases (e.g. in wildcards) and third, if there is no-use cases, why is are regular expression there in the first place? Comment: 5.4 "NAPTR records that are intended to be used for session initiation (including SIP telephony) SHOULD use a SIP URI." "It is RECOMMENDED that authors of ENUM records should always use the SIP or SIPS URI scheme when the service field is 'E2U+sip', and the URIs in question MUST be addresses-of-record, not contact addresses." Another commercial? Comment: 5.4 'E2IPv4+sip' What is this? Comment: 5.6 "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" ." ? I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam problem? Comment: 5. "These guidelines do not by any means exhaustively describe the NAPTR algorithm or the processing of NAPTR records; implementers should familiarize themselves with the DDDS algorithm and ENUM before reviewing this section." MM will like to hear this one ;-) Richard > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@neustar.biz]=20 > Sent: Wednesday, July 02, 2003 10:39 PM > To: enum@ietf.org > Subject: [Enum] Fwd: [Sipping] I-D=20 > ACTION:draft-ietf-sipping-e164-03.txt >=20 >=20 >=20 > FYI >=20 > >To: IETF-Announce: ; > >Cc: sipping@ietf.org > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Date: Wed, 02 Jul 2003 16:33:49 -0400 > >Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt > >Sender: sipping-admin@ietf.org > >X-BeenThere: sipping@ietf.org > >X-Mailman-Version: 2.0.12 > >List-Unsubscribe: , > > > >List-Id: SIPPING Working Group (applications of SIP)=20 > > >List-Post: > >List-Help: > >List-Subscribe: , > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Session Initiation Proposal=20 > Investigation=20 > >Working Group of the IETF. > > > > Title : Using ENUM for SIP Applications > > Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell > > Filename : draft-ietf-sipping-e164-03.txt > > Pages : 22 > > Date : 2003-7-2 > > > >Although SIP was one of the primary applications for which ENUM was=20 > >created, there is nevertheless a need to define procedures for=20 > >integrating ENUM with SIP implementations. This document=20 > illustrates=20 > >how the two protocols might work in concert, and clarifies the=20 > >authoring and processing of ENUM records for SIP applications. > > > >A URL for this Internet-Draft is:=20 > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt > > > >To remove yourself from the IETF Announcement list, send a=20 > message to=20 > >ietf-announce-request with the word unsubscribe in the body of the=20 > >message. > > > >Internet-Drafts are also available by anonymous FTP. Login with the=20 > >username "anonymous" and a password of your e-mail address. After=20 > >logging in, type "cd internet-drafts" and then > > "get draft-ietf-sipping-e164-03.txt". > > > >A list of Internet-Drafts directories can be found in=20 > >http://www.ietf.org/shadow.html or=20 > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-sipping-e164-03.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before=20 > the "FILE" > > command. To decode the response(s), you will need=20 > "munpack" or > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which=20 > have been split > > up into multiple messages), so check your local=20 > documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader=20 > >implementation to automatically retrieve the ASCII version of the=20 > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <2003-7-2161907.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-sipping-e164-03.txt > > > > >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology=20 > Initiatives NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1=20 > 815.333.1237 or=20 ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 3 18:10:55 2003 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 SAA10535 for ; Thu, 3 Jul 2003 18:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCHa-0005F4-V5 for enum-archive@odin.ietf.org; Thu, 03 Jul 2003 18:10:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63MAQDN020142 for enum-archive@odin.ietf.org; Thu, 3 Jul 2003 18:10:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XOCf-0006Mp-NT; Tue, 01 Jul 2003 12:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XOCR-0006MO-8d for enum@optimus.ietf.org; Tue, 01 Jul 2003 12:41:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06910 for ; Tue, 1 Jul 2003 12:41:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XOCN-0006JH-00 for enum@ietf.org; Tue, 01 Jul 2003 12:41:43 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19XOCD-0006If-00 for enum@ietf.org; Tue, 01 Jul 2003 12:41:33 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 89055137F13; Tue, 1 Jul 2003 09:40:35 -0700 (PDT) To: "Conroy, Lawrence (SMTP)" Cc: Stastny Richard , Jeff Williams , enum@ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-dns-threats-03.txt In-Reply-To: Message from "Conroy, Lawrence (SMTP)" of "Tue, 01 Jul 2003 10:45:24 BST." Date: Tue, 01 Jul 2003 09:40:35 -0700 Message-ID: <66505.1057077635@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Lawrence" == Conroy, Lawrence (SMTP) writes: Lawrence> The reasonable answer (looking at our charter) is that, Lawrence> when there's a view of the implications of DNSSEC Lawrence> ->roll-out<- on the ENUM system, it is a perfectly valid Lawrence> thing to discuss these implications on the way that ENUM Lawrence> is used. Indeed. That's precisely what I had in mind for this WG. Who else could and would tackle the DNSSEC issues that would be relevant to how ENUM is (likely to be) used? Lawrence> It need NOT cover the Administration/Social issues like Lawrence> who signs what and who is allowed to sign what, under Lawrence> whose authority, who is responsible for all this, and Lawrence> what is the legal framework, all of which IMHO we can Lawrence> safely leave to the experts :). Yup. This should be out of scope for us too. Lawrence> Seems to me we have a wild agreement going on in this Lawrence> thread. Well the two of us are in wild agreement at any rate... :-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 14:06:46 2003 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 OAA03428 for ; Fri, 4 Jul 2003 14:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUws-0001lK-Ov for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 14:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64I6IHk006774 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 14:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUwc-0001jc-KD; Fri, 04 Jul 2003 14:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUwN-0001j2-HE for enum@optimus.ietf.org; Fri, 04 Jul 2003 14:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03384; Fri, 4 Jul 2003 14:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUwK-0000bS-00; Fri, 04 Jul 2003 14:05:44 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19YUwJ-0000bF-00; Fri, 04 Jul 2003 14:05:44 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h64I5BC29454; Fri, 4 Jul 2003 18:05:11 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 14:06:08 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Fri, 4 Jul 2003 14:05:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Since the original mail was cross-posted between SIPPING and ENUM, I'll send this reply to both. > > General comment: > > It may be a dogma in the religion of SIP, but SIP is not the center of > the world ;-) If you sent an ENUM WG item to another WG, I can imagine someone making a similar comment - "why does this document talk about ENUM all the time, this is a WG about xyz". This document is a SIPPING WG item, not an ENUM WG item. For this document, SIP is effectively the center of the world, yes. I imagine other protocols might similarly describe their relationship to ENUM. But also note that our document talks about more than just ENUM - it also discusses what you might do as a SIP UA when you can't use ENUM, and so on. It also happens to more fully specify ENUM behavior, since we hope that the use of ENUM will be the common case for handling telephone numbers in SIP. > > Comment: > > I am getting a bit tired to be lectured permanently without asking for > it that there is two > types of SIP URIs (if this is such a problem, then why not put a > parameter or create > a sipL: URI) and no contact addresses should appear in ENUM. > As far as I know from praxis, nobody ever tried to do this. > > "SIP URIs in ENUM do not convey capability information. SIP has > its own methods for negotiating capability information between > user agents (see SDP [13], the use of Require/Supported to > negotiate extensions in RFC3261, and callee capabilities [11]); > providing more limited capability information within ENUM is at > best redundant and at worst potentially misleading to SIP's > negotiation system. Also, addresses-of-record do not have > capabilities (only devices registered under an address-of-record > have actual capabilities), and putting contact addresses in ENUM > is not recommended." > > Amen, btw, a tel URI is also an address-of-record (better: a name) and does not > convey any cabability information. On the other hand, if an "author" > want to put capability information in ENUM, it is his problem > Well, I'm sure everyone on the ENUM mailing list has had an earful of these arguments before, agreed. But the products of the IETF are intended for more general consumption than just the participants of any particular WG. SIP/PING WG folk, even, might not have followed these ENUM threads. So maybe there are people out there who, unlike yourself, have not yet grasped this point. It was formerly a subject of confusion, and it might become one again. I hope it isn't too annoying to have this sort of text in the document. > Comment: > "Only one SIP URI appears in an ENUM record set ..." > This is up to the ENUM subscriber, is it necessary for them to read this document? > See also section 5. Authoring of NAPTR records > Well, these do aspire to be guidelines for authors of ENUM NAPTR records for SIP, so yes, we do hope to advise ENUM subscribers, or whomever provisions NAPTR records on their behalf. Obviously, subscribers can read/follow our document or not, as they wish. > Comment: 5.1 > "It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip' > service field whenever the regexp contains a SIP address-of-record URI." > > Are we doing commercials in IETF drafts?. If another enumservice with sip URI > is registered with IANA the "authors" may use, if not, not. I don't really look on this instance (or the others you point out in 5.4) as "commercials" - they are showing a RECOMMENDation from the SIPPING WG on how the documents in the ENUM WG can be used to assist SIP services. If there were multiple possible options for SIP enumservices, surely for consistency it makes sense for the SIPPING WG to make a recommendation? This kind of recommendation is made all the time in IETF documents. Authors of NAPTR records can, of course, reject our advice, and new I-Ds can be authored that teach alternative approaches to authoring. And agreed, another ENUM service might become an RFC and accordingly be registered with the IANA. If you want to argue further that the "E2U+sip" enumservice should not be recommended (and note that it is just RECOMMENDED, not REQUIRED, and then only with the caveat that this enumservice is applicable solely to addresses-of-record), I'd suggest pursuing this directly on the SIPPING list. As far as I know, the consensus of the SIPPING mailing list is that the "E2U+sip" enumservice is sufficient. > Major problem: 5.2 > 5.2 Flags in NAPTR RR > > "Authors of NAPTR records MUST use the terminal "u" flag when > 'E2U+sip' is specified as a Service field." > > Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA > registration. > Good catch - although I'm not sure that I read in rfc2916bis's enumservice registration template that one must specify flags that are meaningful for enumservices within enumservice registrations. But still, my text is really left over from course corrections necessary based on ol' RFC2916 - Section 2.4.1 of RFC2916bis does specify that only the "u" flag is currently defined for ENUM. So I agree with you, Section 5.2 doesn't need to be in the SIPPING document - 2916bis covers this adequately. I'll take it out. > Major problem: 5.3 > "Authors of > records intended to be used for SIP applications SHOULD always use a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." > > I strongly object this. > First, the use of regular expessions is a feature in ENUM and DDDS, > second, there are use cases (e.g. in wildcards) and > third, if there is no-use cases, why is are regular > expression there in > the first place? I agree this is an important issue. While I acknowledge that "wildcards" are possible according to the syntax, what's the use-case that motivates wildcards for ENUM? This is a question I've posed many times, and I've never gotten a good answer to. You'll note that the example from RFC2916 that showed a wildcard has not been repeated in rfc2916bis. The old example showed a record set for 6.4.e164.arpa, and the antecedent of the regexp contained "!^+46(.*)$!". The point I raised about the example was that the "+46*" regexp antecedent didn't do anything - if delegation to 6.4.e164.arpa got you to this record, then of course the regexp was going to match with a leading "+46*". There's no question that regexps are valuable for other DDDS applications - but most DDDS applications don't have anything like ENUM's telephone number resolution system to narrow selection down to a specific record set as a part of DNS operations. The regular expression is there, for example, to match against URN components in order to determine which substitutions are valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see how it would be used. It isn't at all clear that a comparable function is necessary or useful for ENUM - I'm not saying that I'm sure it's not useful, but I am saying that clearly ENUM works without it, and to my knowledge there are no existing use-cases for supplying a regexp antecedent for ENUM NAPTR records. Also, note that the wildcard example begs questions about partial numbers that we're trying to pass over in silence, at least in the current version of RFC2916bis. If you can provide a meaningful use case that doesn't involve partial numbers and/or gateway location that uses wildcards, I'll happily relax this language. > > Comment: 5.4 > > 'E2IPv4+sip' > > What is this? A rhetorical example, as the surrounding context hopefully indicates. It's not meant to be a real enumservice, but is rather a theoretical enumservice that one might invent if one's underlying assumptions were different. Again, I think that is well substantiated by the text of the end of 5.4. > > Comment: 5.6 > > "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . > IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!"." > > ? > I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam > problem? > Heh. > Comment: 5. > > "These guidelines do not by any means exhaustively describe the NAPTR > algorithm or the processing of NAPTR records; implementers should > familiarize themselves with the DDDS algorithm and ENUM before > reviewing this section." > > MM will like to hear this one ;-) > Yes, no desire here to regurgitate the base standard. Jon Peterson NeuStar, Inc. > Richard > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 14:45:32 2003 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 OAA04269 for ; Fri, 4 Jul 2003 14:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVYP-0005bp-0d for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 14:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Ij4cX021555 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 14:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVYL-0005aq-7p; Fri, 04 Jul 2003 14:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVXh-0005Yl-71 for enum@optimus.ietf.org; Fri, 04 Jul 2003 14:44:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04220 for ; Fri, 4 Jul 2003 14:44:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVXe-000111-00 for enum@ietf.org; Fri, 04 Jul 2003 14:44:18 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19YVXd-00010v-00 for enum@ietf.org; Fri, 04 Jul 2003 14:44:17 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jul 2003 20:44:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A1813C9@inno-exchange.innovaphone.com> Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Thread-Index: AcNCVw3soYqSblWzQy26awfPuEVXjwABSFTQ From: "Martin Streller" To: "Peterson, Jon" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, > what's the use-case that motivates > wildcards for ENUM? You can hook up an ENUM client and query for +49 7031 73009 88 our support line. As a result you'll receive an h323 wildcard NAPTR RR that's eventually of interest for you.=20 Replace h323 with sip and you got your use-case. This single NAPTR RR serves the whole range=20 of our two-digit extensions. Regards, Martin -- Martin Streller innovaphone AG Software Engineer Cicerostr. 2A D-10709 Berlin Tel.: +49 (30) 890 44 98 73 Tel.: +49 (7031) 730 09 73 Fax: +49 (30) 890 44 98 96 http://www.innovaphone.com -----Urspr=FCngliche Nachricht----- Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] Gesendet: Freitag, 4. Juli 2003 20:06 An: 'Stastny Richard'; Shockey, Richard; enum@ietf.org; 'sipping@ietf.org' Betreff: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Since the original mail was cross-posted between SIPPING and ENUM, I'll = send this reply to both. >=20 > General comment: >=20 > It may be a dogma in the religion of SIP, but SIP is not the center of > the world ;-) If you sent an ENUM WG item to another WG, I can imagine someone making = a similar comment - "why does this document talk about ENUM all the time, = this is a WG about xyz". This document is a SIPPING WG item, not an ENUM WG = item. For this document, SIP is effectively the center of the world, yes. I imagine other protocols might similarly describe their relationship to = ENUM. But also note that our document talks about more than just ENUM - it = also discusses what you might do as a SIP UA when you can't use ENUM, and so = on. It also happens to more fully specify ENUM behavior, since we hope that = the use of ENUM will be the common case for handling telephone numbers in = SIP. >=20 > Comment:=20 >=20 > I am getting a bit tired to be lectured permanently without asking for = > it that there is two > types of SIP URIs (if this is such a problem, then why not put a=20 > parameter or create > a sipL: URI) and no contact addresses should appear in ENUM.=20 > As far as I know from praxis, nobody ever tried to do this. >=20 > "SIP URIs in ENUM do not convey capability information. SIP has > its own methods for negotiating capability information between > user agents (see SDP [13], the use of Require/Supported to > negotiate extensions in RFC3261, and callee capabilities [11]); > providing more limited capability information within ENUM is at > best redundant and at worst potentially misleading to SIP's > negotiation system. Also, addresses-of-record do not have > capabilities (only devices registered under an address-of-record > have actual capabilities), and putting contact addresses in ENUM > is not recommended." >=20 > Amen, btw, a tel URI is also an address-of-record (better: a name) and does not > convey any cabability information. On the other hand, if an "author" > want to put capability information in ENUM, it is his problem >=20 Well, I'm sure everyone on the ENUM mailing list has had an earful of = these arguments before, agreed. But the products of the IETF are intended for = more general consumption than just the participants of any particular WG. SIP/PING WG folk, even, might not have followed these ENUM threads. So = maybe there are people out there who, unlike yourself, have not yet grasped = this point. It was formerly a subject of confusion, and it might become one again. I hope it isn't too annoying to have this sort of text in the document. > Comment:=20 > "Only one SIP URI appears in an ENUM record set ..." > This is up to the ENUM subscriber, is it necessary for them to read = this document? > See also section 5. Authoring of NAPTR records >=20 Well, these do aspire to be guidelines for authors of ENUM NAPTR records = for SIP, so yes, we do hope to advise ENUM subscribers, or whomever = provisions NAPTR records on their behalf. Obviously, subscribers can read/follow = our document or not, as they wish. > Comment: 5.1 > "It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip'=20 > service field whenever the regexp contains a SIP address-of-record = URI." >=20 > Are we doing commercials in IETF drafts?. If another enumservice with = sip URI > is registered with IANA the "authors" may use, if not, not. I don't really look on this instance (or the others you point out in = 5.4) as "commercials" - they are showing a RECOMMENDation from the SIPPING WG on = how the documents in the ENUM WG can be used to assist SIP services. If = there were multiple possible options for SIP enumservices, surely for = consistency it makes sense for the SIPPING WG to make a recommendation? This kind of recommendation is made all the time in IETF documents. Authors of NAPTR records can, of course, reject our advice, and new I-Ds = can be authored that teach alternative approaches to authoring. And agreed, another ENUM service might become an RFC and accordingly be registered = with the IANA. If you want to argue further that the "E2U+sip" enumservice should not = be recommended (and note that it is just RECOMMENDED, not REQUIRED, and = then only with the caveat that this enumservice is applicable solely to addresses-of-record), I'd suggest pursuing this directly on the SIPPING list. As far as I know, the consensus of the SIPPING mailing list is = that the "E2U+sip" enumservice is sufficient. > Major problem: 5.2 > 5.2 Flags in NAPTR RR >=20 > "Authors of NAPTR records MUST use the terminal "u" flag when > 'E2U+sip' is specified as a Service field." >=20 > Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA > registration. >=20 Good catch - although I'm not sure that I read in rfc2916bis's = enumservice registration template that one must specify flags that are meaningful = for enumservices within enumservice registrations. But still, my text is = really left over from course corrections necessary based on ol' RFC2916 - = Section 2.4.1 of RFC2916bis does specify that only the "u" flag is currently = defined for ENUM. So I agree with you, Section 5.2 doesn't need to be in the = SIPPING document - 2916bis covers this adequately. I'll take it out. > Major problem: 5.3 > "Authors of > records intended to be used for SIP applications SHOULD always use = a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." >=20 > I strongly object this. > First, the use of regular expessions is a feature in ENUM and DDDS, > second, there are use cases (e.g. in wildcards) and > third, if there is no-use cases, why is are regular=20 > expression there in > the first place? I agree this is an important issue. While I acknowledge that "wildcards" = are possible according to the syntax, what's the use-case that motivates wildcards for ENUM? This is a question I've posed many times, and I've never gotten a good answer to. You'll note that the example from RFC2916 that showed a = wildcard has not been repeated in rfc2916bis. The old example showed a record set = for 6.4.e164.arpa, and the antecedent of the regexp contained "!^+46(.*)$!". The point I raised about the example was that the "+46*" regexp = antecedent didn't do anything - if delegation to 6.4.e164.arpa got you to this = record, then of course the regexp was going to match with a leading "+46*". There's no question that regexps are valuable for other DDDS = applications - but most DDDS applications don't have anything like ENUM's telephone = number resolution system to narrow selection down to a specific record set as a part of DNS operations. The regular expression is there, for example, to match against URN components in order to determine which substitutions = are valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see how it would = be used. It isn't at all clear that a comparable function is necessary or useful for ENUM - I'm not saying that I'm sure it's not useful, but I am saying that clearly ENUM works without it, and to my knowledge there are = no existing use-cases for supplying a regexp antecedent for ENUM NAPTR = records. Also, note that the wildcard example begs questions about partial = numbers that we're trying to pass over in silence, at least in the current = version of RFC2916bis. If you can provide a meaningful use case that doesn't = involve partial numbers and/or gateway location that uses wildcards, I'll = happily relax this language. >=20 > Comment: 5.4 >=20 > 'E2IPv4+sip' >=20 > What is this? A rhetorical example, as the surrounding context hopefully indicates. = It's not meant to be a real enumservice, but is rather a theoretical = enumservice that one might invent if one's underlying assumptions were different. = Again, I think that is well substantiated by the text of the end of 5.4. >=20 > Comment: 5.6 >=20 > "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . > IN NAPTR 100 20 "u" "E2U+mailto" = "!^.*$!mailto:info@example.com!"." >=20 > ? > I am glad that at least "email:mailto" is allowed beside SIP ;-) No = spam > problem? >=20 Heh. > Comment: 5. >=20 > "These guidelines do not by any means exhaustively describe the NAPTR > algorithm or the processing of NAPTR records; implementers should > familiarize themselves with the DDDS algorithm and ENUM before > reviewing this section." >=20 > MM will like to hear this one ;-) >=20 Yes, no desire here to regurgitate the base standard. Jon Peterson NeuStar, Inc. > Richard > =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 16:49:17 2003 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 QAA07554 for ; Fri, 4 Jul 2003 16:49:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YXU9-0007X9-4n for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 16:48:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64KmnMw028955 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 16:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YXTN-0007MZ-91; Fri, 04 Jul 2003 16:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YXSw-0007GA-Eh for enum@optimus.ietf.org; Fri, 04 Jul 2003 16:47:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07436 for ; Fri, 4 Jul 2003 16:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YXSu-0002Mb-00 for enum@ietf.org; Fri, 04 Jul 2003 16:47:32 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19YXSt-0002MC-00 for enum@ietf.org; Fri, 04 Jul 2003 16:47:31 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h64KksC30161; Fri, 4 Jul 2003 20:46:57 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 16:47:52 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C6F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Martin Streller'" , "'enum@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Fri, 4 Jul 2003 16:47:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think the example would need to be more concrete for us to understand = how you're using wildcards - what does the NAPTR record look like? And the ORIGIN? Having a single NAPTR record serve an entire 100-number range sounds = like a gateway location application to me. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Martin Streller [mailto:MStreller@innovaphone.com] > Sent: Friday, July 04, 2003 11:44 AM > To: Peterson, Jon; enum@ietf.org > Subject: AW: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.txt >=20 >=20 > Hello, >=20 > > what's the use-case that motivates > > wildcards for ENUM? >=20 > You can hook up an ENUM client and query for > +49 7031 73009 88 > our support line. > As a result you'll receive an h323 wildcard NAPTR RR > that's eventually of interest for you.=20 > Replace h323 with sip and you got your use-case. >=20 > This single NAPTR RR serves the whole range=20 > of our two-digit extensions. >=20 > Regards, Martin > -- > Martin Streller > innovaphone AG > Software Engineer > Cicerostr. 2A > D-10709 Berlin > Tel.: +49 (30) 890 44 98 73 > Tel.: +49 (7031) 730 09 73 > Fax: +49 (30) 890 44 98 96 > http://www.innovaphone.com >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Gesendet: Freitag, 4. Juli 2003 20:06 > An: 'Stastny Richard'; Shockey, Richard; enum@ietf.org; > 'sipping@ietf.org' > Betreff: RE: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.txt >=20 >=20 >=20 > Since the original mail was cross-posted between SIPPING and=20 > ENUM, I'll send > this reply to both. >=20 > >=20 > > General comment: > >=20 > > It may be a dogma in the religion of SIP, but SIP is not=20 > the center of > > the world ;-) >=20 > If you sent an ENUM WG item to another WG, I can imagine=20 > someone making a > similar comment - "why does this document talk about ENUM all=20 > the time, this > is a WG about xyz". This document is a SIPPING WG item, not=20 > an ENUM WG item. > For this document, SIP is effectively the center of the world, yes. I > imagine other protocols might similarly describe their=20 > relationship to ENUM. > But also note that our document talks about more than just=20 > ENUM - it also > discusses what you might do as a SIP UA when you can't use=20 > ENUM, and so on. > It also happens to more fully specify ENUM behavior, since we=20 > hope that the > use of ENUM will be the common case for handling telephone=20 > numbers in SIP. >=20 > >=20 > > Comment:=20 > >=20 > > I am getting a bit tired to be lectured permanently without=20 > asking for=20 > > it that there is two > > types of SIP URIs (if this is such a problem, then why not put a=20 > > parameter or create > > a sipL: URI) and no contact addresses should appear in ENUM.=20 > > As far as I know from praxis, nobody ever tried to do this. > >=20 > > "SIP URIs in ENUM do not convey capability information. SIP has > > its own methods for negotiating capability information = between > > user agents (see SDP [13], the use of Require/Supported to > > negotiate extensions in RFC3261, and callee=20 > capabilities [11]); > > providing more limited capability information within=20 > ENUM is at > > best redundant and at worst potentially misleading to SIP's > > negotiation system. Also, addresses-of-record do not have > > capabilities (only devices registered under an=20 > address-of-record > > have actual capabilities), and putting contact=20 > addresses in ENUM > > is not recommended." > >=20 > > Amen, btw, a tel URI is also an address-of-record (better:=20 > a name) and > does not > > convey any cabability information. On the other hand, if an = "author" > > want to put capability information in ENUM, it is his problem > >=20 >=20 > Well, I'm sure everyone on the ENUM mailing list has had an=20 > earful of these > arguments before, agreed. But the products of the IETF are=20 > intended for more > general consumption than just the participants of any particular WG. > SIP/PING WG folk, even, might not have followed these ENUM=20 > threads. So maybe > there are people out there who, unlike yourself, have not yet=20 > grasped this > point. It was formerly a subject of confusion, and it might become = one > again. I hope it isn't too annoying to have this sort of text in the > document. >=20 > > Comment:=20 > > "Only one SIP URI appears in an ENUM record set ..." > > This is up to the ENUM subscriber, is it necessary for them=20 > to read this > document? > > See also section 5. Authoring of NAPTR records > >=20 >=20 > Well, these do aspire to be guidelines for authors of ENUM=20 > NAPTR records for > SIP, so yes, we do hope to advise ENUM subscribers, or=20 > whomever provisions > NAPTR records on their behalf. Obviously, subscribers can=20 > read/follow our > document or not, as they wish. >=20 > > Comment: 5.1 > > "It is strongly RECOMMENDED that authors of NAPTR records use the > 'E2U+sip'=20 > > service field whenever the regexp contains a SIP=20 > address-of-record URI." > >=20 > > Are we doing commercials in IETF drafts?. If another=20 > enumservice with sip > URI > > is registered with IANA the "authors" may use, if not, not. >=20 > I don't really look on this instance (or the others you point=20 > out in 5.4) as > "commercials" - they are showing a RECOMMENDation from the=20 > SIPPING WG on how > the documents in the ENUM WG can be used to assist SIP=20 > services. If there > were multiple possible options for SIP enumservices, surely=20 > for consistency > it makes sense for the SIPPING WG to make a recommendation?=20 > This kind of > recommendation is made all the time in IETF documents. >=20 > Authors of NAPTR records can, of course, reject our advice,=20 > and new I-Ds can > be authored that teach alternative approaches to authoring.=20 > And agreed, > another ENUM service might become an RFC and accordingly be=20 > registered with > the IANA. >=20 > If you want to argue further that the "E2U+sip" enumservice=20 > should not be > recommended (and note that it is just RECOMMENDED, not=20 > REQUIRED, and then > only with the caveat that this enumservice is applicable solely to > addresses-of-record), I'd suggest pursuing this directly on=20 > the SIPPING > list. As far as I know, the consensus of the SIPPING mailing=20 > list is that > the "E2U+sip" enumservice is sufficient. >=20 > > Major problem: 5.2 > > 5.2 Flags in NAPTR RR > >=20 > > "Authors of NAPTR records MUST use the terminal "u" flag when > > 'E2U+sip' is specified as a Service field." > >=20 > > Why?, and if this is so, it must go into the=20 > draft-ietf-enum-sip IANA > > registration. > >=20 >=20 > Good catch - although I'm not sure that I read in=20 > rfc2916bis's enumservice > registration template that one must specify flags that are=20 > meaningful for > enumservices within enumservice registrations. But still, my=20 > text is really > left over from course corrections necessary based on ol'=20 > RFC2916 - Section > 2.4.1 of RFC2916bis does specify that only the "u" flag is=20 > currently defined > for ENUM. So I agree with you, Section 5.2 doesn't need to be=20 > in the SIPPING > document - 2916bis covers this adequately. I'll take it out. >=20 > > Major problem: 5.3 > > "Authors of > > records intended to be used for SIP applications SHOULD=20 > always use a > > greedy regexp; no use-cases have been identified today in which = a > > different antecedent is necessary." > >=20 > > I strongly object this. > > First, the use of regular expessions is a feature in ENUM and DDDS, > > second, there are use cases (e.g. in wildcards) and > > third, if there is no-use cases, why is are regular=20 > > expression there in > > the first place? >=20 > I agree this is an important issue. While I acknowledge that=20 > "wildcards" are > possible according to the syntax, what's the use-case that motivates > wildcards for ENUM? >=20 > This is a question I've posed many times, and I've never gotten a = good > answer to. You'll note that the example from RFC2916 that=20 > showed a wildcard > has not been repeated in rfc2916bis. The old example showed a=20 > record set for > 6.4.e164.arpa, and the antecedent of the regexp contained=20 > "!^+46(.*)$!". >=20 > The point I raised about the example was that the "+46*"=20 > regexp antecedent > didn't do anything - if delegation to 6.4.e164.arpa got you=20 > to this record, > then of course the regexp was going to match with a leading "+46*". >=20 > There's no question that regexps are valuable for other DDDS=20 > applications - > but most DDDS applications don't have anything like ENUM's=20 > telephone number > resolution system to narrow selection down to a specific=20 > record set as a > part of DNS operations. The regular expression is there, for=20 > example, to > match against URN components in order to determine which=20 > substitutions are > valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see=20 > how it would be > used. It isn't at all clear that a comparable function is necessary = or > useful for ENUM - I'm not saying that I'm sure it's not=20 > useful, but I am > saying that clearly ENUM works without it, and to my=20 > knowledge there are no > existing use-cases for supplying a regexp antecedent for ENUM=20 > NAPTR records. >=20 > Also, note that the wildcard example begs questions about=20 > partial numbers > that we're trying to pass over in silence, at least in the=20 > current version > of RFC2916bis. If you can provide a meaningful use case that=20 > doesn't involve > partial numbers and/or gateway location that uses wildcards,=20 > I'll happily > relax this language. >=20 > >=20 > > Comment: 5.4 > >=20 > > 'E2IPv4+sip' > >=20 > > What is this? >=20 > A rhetorical example, as the surrounding context hopefully=20 > indicates. It's > not meant to be a real enumservice, but is rather a=20 > theoretical enumservice > that one might invent if one's underlying assumptions were=20 > different. Again, > I think that is well substantiated by the text of the end of 5.4. >=20 > >=20 > > Comment: 5.6 > >=20 > > "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > > IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^.*$!sip:user@example.com!" . > > IN NAPTR 100 20 "u" "E2U+mailto"=20 > "!^.*$!mailto:info@example.com!"." > >=20 > > ? > > I am glad that at least "email:mailto" is allowed beside=20 > SIP ;-) No spam > > problem? > >=20 >=20 > Heh. >=20 > > Comment: 5. > >=20 > > "These guidelines do not by any means exhaustively describe=20 > the NAPTR > > algorithm or the processing of NAPTR records; implementers = should > > familiarize themselves with the DDDS algorithm and ENUM before > > reviewing this section." > >=20 > > MM will like to hear this one ;-) > >=20 >=20 > Yes, no desire here to regurgitate the base standard. >=20 > Jon Peterson > NeuStar, Inc. >=20 > > Richard > > =20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 19:15:16 2003 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 TAA12169 for ; Fri, 4 Jul 2003 19:15:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZlQ-0001we-Lk for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 19:14:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64NEm46007472 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 19:14:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZkf-0001sl-F7; Fri, 04 Jul 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZjn-0001bC-T3 for enum@optimus.ietf.org; Fri, 04 Jul 2003 19:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12107 for ; Fri, 4 Jul 2003 19:13:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YZjm-0003t1-00 for enum@ietf.org; Fri, 04 Jul 2003 19:13:06 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19YZjl-0003sx-00 for enum@ietf.org; Fri, 04 Jul 2003 19:13:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 00:12:29 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCA2CD; Sat, 5 Jul 2003 00:12:27 +0100 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Martin Streller'" , "'enum@ietf.org'" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C6F@stntexch2.va.neustar.com> References: <0449D80A0E9B614A83FA9031B07E8D3B257C6F@stntexch2.va.neustar.com> Date: Sat, 5 Jul 2003 00:12:22 +0100 Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 4:47 pm -0400 4/7/03, Peterson, Jon wrote: >I think the example would need to be more concrete for us to understand how >you're using wildcards - what does the NAPTR record look like? And the >ORIGIN? > >Having a single NAPTR record serve an entire 100-number range sounds like a >gateway location application to me. > >Jon Peterson >NeuStar, Inc. > > > In response to Martin's answer to Jon's question on the use case >for wildcards: > > >> Hello, >> >> > what's the use-case that motivates >> > wildcards for ENUM? >> >> You can hook up an ENUM client and query for >> +49 7031 73009 88 >> our support line. >> As a result you'll receive an h323 wildcard NAPTR RR >> that's eventually of interest for you. >> Replace h323 with sip and you got your use-case. >> >> This single NAPTR RR serves the whole range >> of our two-digit extensions. >> > > Regards, Martin To which I add: Hi Jon, Martin, folks, I think I understand the wish to use wildcards; it's extremely tempting if one has a set of H323 or SIP phones. I also understand the concern that these can be like a loaded shotgun - powerful but dangerous. We agonized over this one in the ETSI trials document. However...a gateway location application? Not exactly - if one uses a match term in the consequent part, then isn't this is a single entry that generates a set of h323 or SIP URIs (depending on the particular phone number/AUS passed)? I had thought that a NAPTR in a wildcard will act as a gateway location application only if one has a greedy regexp. What am I missing here? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 19:54:36 2003 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 TAA12840 for ; Fri, 4 Jul 2003 19:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YaNS-0004fK-VD for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 19:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Ns6BU017900 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 19:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YaNM-0004eJ-MQ; Fri, 04 Jul 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YaMf-0004Vw-LN for enum@optimus.ietf.org; Fri, 04 Jul 2003 19:53:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12801 for ; Fri, 4 Jul 2003 19:53:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YaMd-000464-00 for enum@ietf.org; Fri, 04 Jul 2003 19:53:15 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19YaMc-00045Y-00 for enum@ietf.org; Fri, 04 Jul 2003 19:53:15 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h64NqhL4077503 for ; Sat, 5 Jul 2003 01:52:44 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307042352.h64NqhL4077503@bartok.sidn.nl> To: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Sat, 05 Jul 2003 00:12:22 +0100. Date: Sat, 05 Jul 2003 01:52:43 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I had thought that a NAPTR in a wildcard will act as a gateway location application only if one has a greedy regexp. What am I missing here? Basic understanding how wildcards in DNS work/are a problem. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 23:16:46 2003 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 XAA16097 for ; Fri, 4 Jul 2003 23:16:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdX8-0001Nb-8U for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 23:16:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h653GIib005296 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 23:16:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdWs-0001Jd-Dt; Fri, 04 Jul 2003 23:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdW0-0001J3-1N for enum@optimus.ietf.org; Fri, 04 Jul 2003 23:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16012; Fri, 4 Jul 2003 23:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YdVy-0005nw-00; Fri, 04 Jul 2003 23:15:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YdVx-0005ng-00; Fri, 04 Jul 2003 23:15:05 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 05:14:50 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h653B9PQ027747; Sat, 5 Jul 2003 05:12:30 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:14:13 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:14:12 +0200 Date: Sat, 5 Jul 2003 05:14:06 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 03:14:12.0688 (UTC) FILETIME=[82221500:01C342A3] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jul 4, 2003, at 20:05 Europe/Stockholm, Peterson, Jon wrote: > I agree this is an important issue. While I acknowledge that > "wildcards" are > possible according to the syntax, what's the use-case that motivates > wildcards for ENUM? Because support for wildcards is a MUST when you implement the NAPTR record, which ENUM inherits from the DDDS application. If you don't implement it, you loose. You don't have a DDDS compliant implementation. So, I don't understand why you do this recommendation. What is it supposed to help wit, as implementations still have to implement the regexp according to the NAPTR specification. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 23:18:30 2003 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 XAA16137 for ; Fri, 4 Jul 2003 23:18:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdYo-0001hR-6l for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 23:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h653I2H0006495 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 23:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdYn-0001gO-T6; Fri, 04 Jul 2003 23:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdYe-0001g6-Vd for enum@optimus.ietf.org; Fri, 04 Jul 2003 23:17:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16128; Fri, 4 Jul 2003 23:17:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YdYd-0005pf-00; Fri, 04 Jul 2003 23:17:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YdYc-0005pQ-00; Fri, 04 Jul 2003 23:17:50 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 05:17:35 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h653FFkF028009; Sat, 5 Jul 2003 05:15:15 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:17:19 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:17:19 +0200 Date: Sat, 5 Jul 2003 05:17:13 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> Message-Id: <2C53CF10-AE97-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 03:17:19.0487 (UTC) FILETIME=[F17958F0:01C342A3] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jul 4, 2003, at 20:05 Europe/Stockholm, Peterson, Jon wrote: > You'll note that the example from RFC2916 that showed a wildcard > has not been repeated in rfc2916bis. The old example showed a record > set for > 6.4.e164.arpa, and the antecedent of the regexp contained > "!^+46(.*)$!". You can have something like this (I think, straight from my head): 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 4 23:22:29 2003 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 XAA16181 for ; Fri, 4 Jul 2003 23:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ydcf-00021d-5z for enum-archive@odin.ietf.org; Fri, 04 Jul 2003 23:22:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h653M1DU007763 for enum-archive@odin.ietf.org; Fri, 4 Jul 2003 23:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ydce-00020q-KG; Fri, 04 Jul 2003 23:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ydbi-0001sk-MS for enum@optimus.ietf.org; Fri, 04 Jul 2003 23:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16175 for ; Fri, 4 Jul 2003 23:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ydbg-0005qr-00 for enum@ietf.org; Fri, 04 Jul 2003 23:21:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Ydbg-0005qo-00 for enum@ietf.org; Fri, 04 Jul 2003 23:21:00 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 05:20:44 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h653IPm9028242; Sat, 5 Jul 2003 05:18:25 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:20:29 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:20:29 +0200 Date: Sat, 5 Jul 2003 05:20:21 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org To: Jaap Akkerhuis From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200307042352.h64NqhL4077503@bartok.sidn.nl> Message-Id: <9C7A26E8-AE97-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 03:20:29.0427 (UTC) FILETIME=[62AFE430:01C342A4] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On l=F6rdag, jul 5, 2003, at 01:52 Europe/Stockholm, Jaap Akkerhuis = wrote: > > > I had thought that a NAPTR in a wildcard will act as a gateway=20 > location > application only if one has a greedy regexp. What am I missing=20 > here? > > Basic understanding how wildcards in DNS work/are a problem. Yes, but _if_ the DNS community say "using wildcards in DNS is ok"=20 _then_ ENUM will be able to use it fully as we inherit the regexp in=20 the DDDS specification. With my DNS hat on, I would still though say "if you use wildcards in=20 DNS, you really really really must understand the implications, so you=20= better try to solve the problem you have in some other way first". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 06:06:45 2003 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 GAA04407 for ; Sat, 5 Jul 2003 06:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjvv-0007kf-Qq for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 06:06:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65A6JXe029793 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 06:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjvc-0007io-T3; Sat, 05 Jul 2003 06:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjue-0007hz-Mt for enum@optimus.ietf.org; Sat, 05 Jul 2003 06:05:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04337; Sat, 5 Jul 2003 06:04:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Yjub-000096-00; Sat, 05 Jul 2003 06:04:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19YjuZ-000092-00; Sat, 05 Jul 2003 06:04:56 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 5 Jul 2003 12:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233712@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcNCpDIkgMmCUmfAQjCStselWm3GWQANeech From: "Stastny Richard" To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Peterson, Jon" , Cc: "Shockey, Richard" , , Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 U2VlIGJlbG93DQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog UGF0cmlrIEbDpGx0c3Ryw7ZtIFttYWlsdG86cGFmQGNpc2NvLmNvbV0gDQoJR2VzZW5kZXQ6IFNh IDA1LjA3LjIwMDMgMDU6MTQgDQoJQW46IFBldGVyc29uLCBKb24gDQoJQ2M6IFN0YXN0bnkgUmlj aGFyZDsgU2hvY2tleSwgUmljaGFyZDsgZW51bUBpZXRmLm9yZzsgJ3NpcHBpbmdAaWV0Zi5vcmcn IA0KCUJldHJlZmY6IFJlOiBbRW51bV0gRndkOiBbU2lwcGluZ10gSS1EIEFDVElPTjpkcmFmdC1p ZXRmLXNpcHBpbmctZTE2NC0wMy50IHh0DQoJDQoJDQoNCglPbiBmcmVkYWcsIGp1bCA0LCAyMDAz LCBhdCAyMDowNSBFdXJvcGUvU3RvY2tob2xtLCBQZXRlcnNvbiwgSm9uIHdyb3RlOg0KCQ0KCT4g SSBhZ3JlZSB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZS4gV2hpbGUgSSBhY2tub3dsZWRnZSB0 aGF0DQoJPiAid2lsZGNhcmRzIiBhcmUNCgk+IHBvc3NpYmxlIGFjY29yZGluZyB0byB0aGUgc3lu dGF4LCB3aGF0J3MgdGhlIHVzZS1jYXNlIHRoYXQgbW90aXZhdGVzDQoJPiB3aWxkY2FyZHMgZm9y IEVOVU0/DQoJDQoJQmVjYXVzZSBzdXBwb3J0IGZvciB3aWxkY2FyZHMgaXMgYSBNVVNUIHdoZW4g eW91IGltcGxlbWVudCB0aGUgTkFQVFINCglyZWNvcmQsIHdoaWNoIEVOVU0gaW5oZXJpdHMgZnJv bSB0aGUgREREUyBhcHBsaWNhdGlvbi4gSWYgeW91IGRvbid0DQoJaW1wbGVtZW50IGl0LCB5b3Ug bG9vc2UuIFlvdSBkb24ndCBoYXZlIGEgREREUyBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24uDQoJ DQoJU28sIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91IGRvIHRoaXMgcmVjb21tZW5kYXRpb24u IFdoYXQgaXMgaXQNCglzdXBwb3NlZCB0byBoZWxwIHdpdCwgYXMgaW1wbGVtZW50YXRpb25zIHN0 aWxsIGhhdmUgdG8gaW1wbGVtZW50IHRoZQ0KCXJlZ2V4cCBhY2NvcmRpbmcgdG8gdGhlIE5BUFRS IHNwZWNpZmljYXRpb24uDQoJDQoJICAgICBwYWYNCgktLS0tLS0tDQoNCglUbyB3aGljaCBJIHJl cGx5IHRvIEpvbiBhbmQgUGF0cmlrOg0KDQoJTWFydGluIFN0cmVsbGVyIGdhdmUgYWxyZWFkeSBv bmUgZXhhbXBsZS4gDQoNCglpdCBpcyB1c2VkIGZvciBwb2ludGluZyB0byB3aG9sZSByYW5nZSBv ZiBwYXJ0aWFsIG51bWJlcnMgb2YgYSBQQlguIFRoZSB0ZXJtICJQYXJ0aWFsIG51bWJlcnMiIGlz IHVzZWQgaGVyZSBpbiB0aGUgY29udGV4dCBvZiBFLjE2NCBBbm5leCBCLiBXaGF0IHlvdSBjYWxs IHBhcnRpYWwgbnVtYmVycyBJIGNhbGwgaW5jb21wbGV0ZSBudW1iZXJzLg0KDQoJSSBoYXZlIHRv IGFkbWl0IHRoYXQgYWxzbyB3aXRoaW4gb3VyIHRyYWlscyB0aGVyZSBhcmUgdHdvIHNjaG9vbHMg b2YgdGhvdWdodDogT25lIHByb3Bvc2luZyB0aGUgdXNlIG9mIHdpbGRjYXJkcyBhbmQgcmVnZXhw IGZvciB0aGlzLCB0aGUgb3RoZXJzIChtb3N0bHkgRE5TIHBlb3BsZSBoYXZpbmcgYW4gaG9ycm9y IG9mIHdpbGRjYXJkcykgYXJlIHByb3Bvc2luZyBqdXN0IHRvIGdlbmVyYXRlIHpvbmUgZW50cmll cyBmb3IgZWFjaCBmdWxsIG51bWJlci4NCg0KCVRoZSBmaXJzdCBhcHByb2FjaCBoYXMgdGhlIGRy YXdiYWNrIHRoYXQgaXQgb25seSB3b3JrcyBpZiBhbGwgZW50aWVzIGFyZSBzaW1pbGFyIGFuZCBh bHNvIGlmIHRoZXJlIGlzIG9ubHkgb25lIE5BUFRSIHBlciBudW1iZXIgcG9pbnRpbmcgdG8gdGhl IHNhbWUgc2VydmljZSAoZS5nLiBzaXApLiBFc3BlY2lhbGx5IHlvdSBzaG91bGQgbGlrZSB0aGlz IDstKQ0KDQoJVGhlIG90aGVyIGV4YW1wbGUgaXMgdGhlIGV2ZW4gbW9yZSBnZW5lcmljIGFwcHJv YWNoIFBhdHJpayB3YXMgdGFsa2luZyBhYm91dCBhbmQgd2h5IHdlIHdhbnRlZCB0aGUgZW51bS1V Ukkgb3IgdGhlICJhbGwiIG9yICIqIiBlbnVtc2VydmljZTogSXRzIHRoZSBjb2RlLXNwbGl0IGV4 YW1wbGUsIGUuZyBpZiB5b3UgaGF2ZSB0d28gZGlmZmVyZW50IGFyZWEgY29kZXMgcnVubmluZyBw YXJhbGxlbC4gQlRXIFBhdHJpaywgSSBkbyBub3QgdW5kZXJzdGFuZCBxdWl0ZSB5b3VyIGV4YW1w bGUuDQoNCglUaGVyZSBtYXkgYmUgbW9yZSBleGFtcGxlcy4NCg0KCUp1c3Qgb25lIGNvbW1lbnQg dG8geW91ciBkcmFmdCANCg0KCWluIGdlbmVyYWw6IEkgYWxzbyBjb25zaWRlciBpdCBuZWNlc3Nh cnkgdG8gaGF2ZSBzYW1lIGtpbmQgb2YgQkNQIG9uIGVudW0sIGJ1dCBJTUhPIGl0IGlzIHN0aWxs IHRvbyBlYXJseSB0byBkbyB0aGlzLiBXZSBuZWVkIG1vcmUgcHJhY3RpY2FsIGV4cGVyaWVuY2Ug c3RpbGwuIEFuZCBpdCBzaG91bGQgYmUgZG9uZSBieSB0aGUgZW51bSBXRywgbWF5YmUgd2l0aCBp bnB1dHMgZnJvbSBvdGhlciBncm91cHMuDQoNCglyZWdhcmRzDQoNCglSaWNoYXJkDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 06:34:28 2003 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 GAA04942 for ; Sat, 5 Jul 2003 06:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YkMk-0000pE-Vm for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 06:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65AY2IG003168 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 06:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YkMi-0000oj-K4; Sat, 05 Jul 2003 06:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YkLw-0000l0-7g for enum@optimus.ietf.org; Sat, 05 Jul 2003 06:33:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04935 for ; Sat, 5 Jul 2003 06:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YkLs-0000Ke-00 for enum@ietf.org; Sat, 05 Jul 2003 06:33:08 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19YkLr-0000Kb-00 for enum@ietf.org; Sat, 05 Jul 2003 06:33:07 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Jul 2003 12:32:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A1813CA@inno-exchange.innovaphone.com> Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Thread-Index: AcNCbWaqDylr+w/fQyiJtrw4LxFk1wAcYYWg From: "Martin Streller" To: "Peterson, Jon" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jon. yes you're right, it's a gateway location application. The NAPTR: $ORIGIN 9.0.0.3.7.1.3.0.7.9.4.e164.arpa. ; NAPTR order pref flags service regexpression = replacement * NAPTR 100 100 "u" "E2U+h323:voice" = "!^\+49703173009(.*)$!h323:\1@gw-amt.innovaphone.com!" . The outcome of a query for +49 7031 73009 88 : h323:88@gw-amt.innovaphone.com This wildcard record is hosted officially by Deutsche Telekom,T-Systems = within a BIND9 Dns server (with the exception that every \ must be written as a = \\). Martin -----Urspr=FCngliche Nachricht----- Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] Gesendet: Freitag, 4. Juli 2003 22:48 An: Martin Streller; 'enum@ietf.org' Betreff: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt I think the example would need to be more concrete for us to understand = how you're using wildcards - what does the NAPTR record look like? And the ORIGIN? Having a single NAPTR record serve an entire 100-number range sounds = like a gateway location application to me. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Martin Streller [mailto:MStreller@innovaphone.com] > Sent: Friday, July 04, 2003 11:44 AM > To: Peterson, Jon; enum@ietf.org > Subject: AW: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.txt >=20 >=20 > Hello, >=20 > > what's the use-case that motivates > > wildcards for ENUM? >=20 > You can hook up an ENUM client and query for > +49 7031 73009 88 > our support line. > As a result you'll receive an h323 wildcard NAPTR RR > that's eventually of interest for you.=20 > Replace h323 with sip and you got your use-case. >=20 > This single NAPTR RR serves the whole range=20 > of our two-digit extensions. >=20 > Regards, Martin > -- > Martin Streller > innovaphone AG > Software Engineer > Cicerostr. 2A > D-10709 Berlin > Tel.: +49 (30) 890 44 98 73 > Tel.: +49 (7031) 730 09 73 > Fax: +49 (30) 890 44 98 96 > http://www.innovaphone.com >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Gesendet: Freitag, 4. Juli 2003 20:06 > An: 'Stastny Richard'; Shockey, Richard; enum@ietf.org; > 'sipping@ietf.org' > Betreff: RE: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.txt >=20 >=20 >=20 > Since the original mail was cross-posted between SIPPING and=20 > ENUM, I'll send > this reply to both. >=20 > >=20 > > General comment: > >=20 > > It may be a dogma in the religion of SIP, but SIP is not=20 > the center of > > the world ;-) >=20 > If you sent an ENUM WG item to another WG, I can imagine=20 > someone making a > similar comment - "why does this document talk about ENUM all=20 > the time, this > is a WG about xyz". This document is a SIPPING WG item, not=20 > an ENUM WG item. > For this document, SIP is effectively the center of the world, yes. I > imagine other protocols might similarly describe their=20 > relationship to ENUM. > But also note that our document talks about more than just=20 > ENUM - it also > discusses what you might do as a SIP UA when you can't use=20 > ENUM, and so on. > It also happens to more fully specify ENUM behavior, since we=20 > hope that the > use of ENUM will be the common case for handling telephone=20 > numbers in SIP. >=20 > >=20 > > Comment:=20 > >=20 > > I am getting a bit tired to be lectured permanently without=20 > asking for=20 > > it that there is two > > types of SIP URIs (if this is such a problem, then why not put a=20 > > parameter or create > > a sipL: URI) and no contact addresses should appear in ENUM.=20 > > As far as I know from praxis, nobody ever tried to do this. > >=20 > > "SIP URIs in ENUM do not convey capability information. SIP has > > its own methods for negotiating capability information between > > user agents (see SDP [13], the use of Require/Supported to > > negotiate extensions in RFC3261, and callee=20 > capabilities [11]); > > providing more limited capability information within=20 > ENUM is at > > best redundant and at worst potentially misleading to SIP's > > negotiation system. Also, addresses-of-record do not have > > capabilities (only devices registered under an=20 > address-of-record > > have actual capabilities), and putting contact=20 > addresses in ENUM > > is not recommended." > >=20 > > Amen, btw, a tel URI is also an address-of-record (better:=20 > a name) and > does not > > convey any cabability information. On the other hand, if an "author" > > want to put capability information in ENUM, it is his problem > >=20 >=20 > Well, I'm sure everyone on the ENUM mailing list has had an=20 > earful of these > arguments before, agreed. But the products of the IETF are=20 > intended for more > general consumption than just the participants of any particular WG. > SIP/PING WG folk, even, might not have followed these ENUM=20 > threads. So maybe > there are people out there who, unlike yourself, have not yet=20 > grasped this > point. It was formerly a subject of confusion, and it might become one > again. I hope it isn't too annoying to have this sort of text in the > document. >=20 > > Comment:=20 > > "Only one SIP URI appears in an ENUM record set ..." > > This is up to the ENUM subscriber, is it necessary for them=20 > to read this > document? > > See also section 5. Authoring of NAPTR records > >=20 >=20 > Well, these do aspire to be guidelines for authors of ENUM=20 > NAPTR records for > SIP, so yes, we do hope to advise ENUM subscribers, or=20 > whomever provisions > NAPTR records on their behalf. Obviously, subscribers can=20 > read/follow our > document or not, as they wish. >=20 > > Comment: 5.1 > > "It is strongly RECOMMENDED that authors of NAPTR records use the > 'E2U+sip'=20 > > service field whenever the regexp contains a SIP=20 > address-of-record URI." > >=20 > > Are we doing commercials in IETF drafts?. If another=20 > enumservice with sip > URI > > is registered with IANA the "authors" may use, if not, not. >=20 > I don't really look on this instance (or the others you point=20 > out in 5.4) as > "commercials" - they are showing a RECOMMENDation from the=20 > SIPPING WG on how > the documents in the ENUM WG can be used to assist SIP=20 > services. If there > were multiple possible options for SIP enumservices, surely=20 > for consistency > it makes sense for the SIPPING WG to make a recommendation?=20 > This kind of > recommendation is made all the time in IETF documents. >=20 > Authors of NAPTR records can, of course, reject our advice,=20 > and new I-Ds can > be authored that teach alternative approaches to authoring.=20 > And agreed, > another ENUM service might become an RFC and accordingly be=20 > registered with > the IANA. >=20 > If you want to argue further that the "E2U+sip" enumservice=20 > should not be > recommended (and note that it is just RECOMMENDED, not=20 > REQUIRED, and then > only with the caveat that this enumservice is applicable solely to > addresses-of-record), I'd suggest pursuing this directly on=20 > the SIPPING > list. As far as I know, the consensus of the SIPPING mailing=20 > list is that > the "E2U+sip" enumservice is sufficient. >=20 > > Major problem: 5.2 > > 5.2 Flags in NAPTR RR > >=20 > > "Authors of NAPTR records MUST use the terminal "u" flag when > > 'E2U+sip' is specified as a Service field." > >=20 > > Why?, and if this is so, it must go into the=20 > draft-ietf-enum-sip IANA > > registration. > >=20 >=20 > Good catch - although I'm not sure that I read in=20 > rfc2916bis's enumservice > registration template that one must specify flags that are=20 > meaningful for > enumservices within enumservice registrations. But still, my=20 > text is really > left over from course corrections necessary based on ol'=20 > RFC2916 - Section > 2.4.1 of RFC2916bis does specify that only the "u" flag is=20 > currently defined > for ENUM. So I agree with you, Section 5.2 doesn't need to be=20 > in the SIPPING > document - 2916bis covers this adequately. I'll take it out. >=20 > > Major problem: 5.3 > > "Authors of > > records intended to be used for SIP applications SHOULD=20 > always use a > > greedy regexp; no use-cases have been identified today in which a > > different antecedent is necessary." > >=20 > > I strongly object this. > > First, the use of regular expessions is a feature in ENUM and DDDS, > > second, there are use cases (e.g. in wildcards) and > > third, if there is no-use cases, why is are regular=20 > > expression there in > > the first place? >=20 > I agree this is an important issue. While I acknowledge that=20 > "wildcards" are > possible according to the syntax, what's the use-case that motivates > wildcards for ENUM? >=20 > This is a question I've posed many times, and I've never gotten a good > answer to. You'll note that the example from RFC2916 that=20 > showed a wildcard > has not been repeated in rfc2916bis. The old example showed a=20 > record set for > 6.4.e164.arpa, and the antecedent of the regexp contained=20 > "!^+46(.*)$!". >=20 > The point I raised about the example was that the "+46*"=20 > regexp antecedent > didn't do anything - if delegation to 6.4.e164.arpa got you=20 > to this record, > then of course the regexp was going to match with a leading "+46*". >=20 > There's no question that regexps are valuable for other DDDS=20 > applications - > but most DDDS applications don't have anything like ENUM's=20 > telephone number > resolution system to narrow selection down to a specific=20 > record set as a > part of DNS operations. The regular expression is there, for=20 > example, to > match against URN components in order to determine which=20 > substitutions are > valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see=20 > how it would be > used. It isn't at all clear that a comparable function is necessary or > useful for ENUM - I'm not saying that I'm sure it's not=20 > useful, but I am > saying that clearly ENUM works without it, and to my=20 > knowledge there are no > existing use-cases for supplying a regexp antecedent for ENUM=20 > NAPTR records. >=20 > Also, note that the wildcard example begs questions about=20 > partial numbers > that we're trying to pass over in silence, at least in the=20 > current version > of RFC2916bis. If you can provide a meaningful use case that=20 > doesn't involve > partial numbers and/or gateway location that uses wildcards,=20 > I'll happily > relax this language. >=20 > >=20 > > Comment: 5.4 > >=20 > > 'E2IPv4+sip' > >=20 > > What is this? >=20 > A rhetorical example, as the surrounding context hopefully=20 > indicates. It's > not meant to be a real enumservice, but is rather a=20 > theoretical enumservice > that one might invent if one's underlying assumptions were=20 > different. Again, > I think that is well substantiated by the text of the end of 5.4. >=20 > >=20 > > Comment: 5.6 > >=20 > > "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > > IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^.*$!sip:user@example.com!" . > > IN NAPTR 100 20 "u" "E2U+mailto"=20 > "!^.*$!mailto:info@example.com!"." > >=20 > > ? > > I am glad that at least "email:mailto" is allowed beside=20 > SIP ;-) No spam > > problem? > >=20 >=20 > Heh. >=20 > > Comment: 5. > >=20 > > "These guidelines do not by any means exhaustively describe=20 > the NAPTR > > algorithm or the processing of NAPTR records; implementers should > > familiarize themselves with the DDDS algorithm and ENUM before > > reviewing this section." > >=20 > > MM will like to hear this one ;-) > >=20 >=20 > Yes, no desire here to regurgitate the base standard. >=20 > Jon Peterson > NeuStar, Inc. >=20 > > Richard > > =20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 07:52:35 2003 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 HAA05896 for ; Sat, 5 Jul 2003 07:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlaJ-0003zC-7b for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 07:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65Bq7R7015311 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 07:52:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlaC-0003yS-L9; Sat, 05 Jul 2003 07:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlZW-0003y6-3F for enum@optimus.ietf.org; Sat, 05 Jul 2003 07:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05885; Sat, 5 Jul 2003 07:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YlZU-0000cl-00; Sat, 05 Jul 2003 07:51:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YlZU-0000ch-00; Sat, 05 Jul 2003 07:51:16 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 13:50:59 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h65BmdjZ000439; Sat, 5 Jul 2003 13:48:39 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 13:50:43 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 13:50:43 +0200 Date: Sat, 5 Jul 2003 13:50:37 +0200 Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Peterson, Jon" , , "Shockey, Richard" , , To: "Stastny Richard" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <06CF906FE3998C4E944213062009F162233712@oefeg-s02.oefeg.loc> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 11:50:43.0448 (UTC) FILETIME=[AA10C780:01C342EB] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On l=F6rdag, jul 5, 2003, at 12:08 Europe/Stockholm, Stastny Richard=20 wrote: > I have to admit that also within our trails there are two = schools of=20 > thought: One proposing the use of wildcards and regexp for this, the=20= > others (mostly DNS people having an horror of wildcards) are proposing=20= > just to generate zone entries for each full number. Don't mix up using wildcard in DNS with the regular expression issues.=20= They are two different issues, and should be kept separate. That's why=20= I gave an example without the wildcard in DNS. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 13:01:45 2003 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 NAA11363 for ; Sat, 5 Jul 2003 13:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YqPX-0007Nf-1G for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 13:01:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65H1Jtj028368 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 13:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YqPF-0007Lt-CC; Sat, 05 Jul 2003 13:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YqON-0007LH-8u for enum@optimus.ietf.org; Sat, 05 Jul 2003 13:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11341 for ; Sat, 5 Jul 2003 13:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YqOK-0003ii-00 for enum@ietf.org; Sat, 05 Jul 2003 13:00:05 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19YqOK-0003iH-00 for enum@ietf.org; Sat, 05 Jul 2003 13:00:04 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 17:59:33 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCA22T; Sat, 5 Jul 2003 17:59:30 +0100 From: "Conroy, Lawrence (SMTP)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Stastny Richard Cc: "Peterson, Jon" , MStreller@innovaphone.com, "Shockey, Richard" , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sat, 5 Jul 2003 17:59:24 +0100 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Enum] Use of DNS Wildcards in ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable {pruned to ENUM list only and thread renamed - was "Re: AW: [Enum] Fwd: [Sipping] I-D=20 ACTION:draft-ietf-sipping-e164-03.txt"} At 1:50 pm +0200 5/7/03, Patrik F=E4ltstr=F6m wrote: >On l=F6rdag, jul 5, 2003, at 12:08 Europe/Stockholm, Stastny Richard = wrote: > >> I have to admit that also within our trails there are two=20 >>schools of thought: One proposing the use of wildcards and regexp=20 >>for this, the others (mostly DNS people having an horror of=20 >>wildcards) are proposing just to generate zone entries for each=20 >>full number. > >Don't mix up using wildcard in DNS with the regular expression=20 >issues. They are two different issues, and should be kept separate.=20 >That's why I gave an example without the wildcard in DNS. > > paf Hi Patrik, folks, I don't think Richard was mixing them up - but they can be used = together and they do have a similar chance of screwing up. One could use a provisioning system to write lots of individual "hard = coded" entries for each of the numbers in a range (with our without a "greedy" = regexp) [as has been proposed by the US ENUMF for area code splits, if I=20 understand aright] or you could write a single DNS wildcard entry with a "greedy regexp" = to mean everything in this range goes to here, or you could write a single DNS wildcard entry with a more complex=20 regexp (either as a gateway locator or to support other goals). I've seen all of these = cases. So far I haven't seen a non-terminal, but I live in hope. The issue I can see with a DNS wildcard is that the entry will be=20 processed IF there isn't a delegation, and IF there is no more specific matching entry=20 "under" the wildcard; IF so then it might "fire" for an incomplete number. Thus, depending=20 on the TechC's intentions, wildcards need to be considered in detail before trying=20 to use them. Loaded shotgun - do not juggle unless very practiced. As a *separate* issue, regexps can be fun as well - hands up all who = have populated an ENUM zone with an incorrect regexp, resulting in = completely the wrong URI - mine's up (several times :). Loaded pistols - juggle only in SG2 meetings. all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 15:39:41 2003 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 PAA14853 for ; Sat, 5 Jul 2003 15:39:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YssL-00054w-3N for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 15:39:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65JdDrm019522 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 15:39:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yss9-00054J-EH; Sat, 05 Jul 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ysrw-00053l-RI for enum@optimus.ietf.org; Sat, 05 Jul 2003 15:38:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14840 for ; Sat, 5 Jul 2003 15:38:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ysru-00059G-00 for enum@ietf.org; Sat, 05 Jul 2003 15:38:46 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19Ysrt-00059D-00 for enum@ietf.org; Sat, 05 Jul 2003 15:38:46 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Jul 2003 21:38:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A1813CB@inno-exchange.innovaphone.com> Thread-Topic: Use of DNS Wildcards in ENUM Thread-Index: AcNDFtRvpL810WD6TuC+6hlyZsAOfgAE1B/w From: "Martin Streller" To: "Conroy, Lawrence (SMTP)" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Stastny Richard" Cc: "Peterson, Jon" , "Shockey, Richard" , Content-Transfer-Encoding: quoted-printable Subject: [Enum] AW: Use of DNS Wildcards in ENUM Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Lawrence, >IF so then it might "fire" for an incomplete number. Thus, depending=20 >on the TechC's... It depends on the point of view, if this is considered to be a problem or a solicited feature. E.g. in H.323 such a dialling behaviour is well-known as=20 overlapped-dialling. All the more - overlapped-dialling is crucial if you wanted to resemble the way people are phoning today. People hook-off their phone and start to dial. One digit by the=20 other and w/o waiting until an intermediate something might view the number as being complete. So, if you asked me I'd vote for "yes, pls. let it fire for incomplete numbers". Btw, similar reflections apply for overdialling, i.e. you're providing=20 more numbers than actually required. This also doesn't impose any harm. Martin -----Urspr=FCngliche Nachricht----- Von: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] Gesendet: Samstag, 5. Juli 2003 18:59 An: Patrik F=E4ltstr=F6m; Stastny Richard Cc: Peterson, Jon; Martin Streller; Shockey, Richard; enum@ietf.org Betreff: Use of DNS Wildcards in ENUM {pruned to ENUM list only and thread renamed - was "Re: AW: [Enum] Fwd: [Sipping] I-D=20 ACTION:draft-ietf-sipping-e164-03.txt"} At 1:50 pm +0200 5/7/03, Patrik F=E4ltstr=F6m wrote: >On l=F6rdag, jul 5, 2003, at 12:08 Europe/Stockholm, Stastny Richard = wrote: > >> I have to admit that also within our trails there are two=20 >>schools of thought: One proposing the use of wildcards and regexp=20 >>for this, the others (mostly DNS people having an horror of=20 >>wildcards) are proposing just to generate zone entries for each=20 >>full number. > >Don't mix up using wildcard in DNS with the regular expression=20 >issues. They are two different issues, and should be kept separate.=20 >That's why I gave an example without the wildcard in DNS. > > paf Hi Patrik, folks, I don't think Richard was mixing them up - but they can be used = together and they do have a similar chance of screwing up. One could use a provisioning system to write lots of individual "hard = coded" entries for each of the numbers in a range (with our without a "greedy" = regexp) [as has been proposed by the US ENUMF for area code splits, if I=20 understand aright] or you could write a single DNS wildcard entry with a "greedy regexp" to = mean everything in this range goes to here, or you could write a single DNS wildcard entry with a more complex=20 regexp (either as a gateway locator or to support other goals). I've seen all of these = cases. So far I haven't seen a non-terminal, but I live in hope. The issue I can see with a DNS wildcard is that the entry will be=20 processed IF there isn't a delegation, and IF there is no more specific matching entry=20 "under" the wildcard; IF so then it might "fire" for an incomplete number. Thus, depending=20 on the TechC's intentions, wildcards need to be considered in detail before trying=20 to use them. Loaded shotgun - do not juggle unless very practiced. As a *separate* issue, regexps can be fun as well - hands up all who = have populated an ENUM zone with an incorrect regexp, resulting in completely the wrong URI - mine's up (several times :). Loaded pistols - juggle only in SG2 meetings. all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, = Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is = confidential to Roke Manor Research Ltd and must not be passed to any third party = without permission. This communication is for information only and shall not = create or change any contractual relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 5 20:25:54 2003 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 UAA20751 for ; Sat, 5 Jul 2003 20:25:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxLL-0005tx-1q for enum-archive@odin.ietf.org; Sat, 05 Jul 2003 20:25:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h660PReA022641 for enum-archive@odin.ietf.org; Sat, 5 Jul 2003 20:25:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxKw-0005pj-7m; Sat, 05 Jul 2003 20:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxKf-0005mk-F8 for enum@optimus.ietf.org; Sat, 05 Jul 2003 20:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20701; Sat, 5 Jul 2003 20:24:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YxKa-0006Xj-00; Sat, 05 Jul 2003 20:24:40 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19YxKZ-0006Xf-00; Sat, 05 Jul 2003 20:24:39 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h660NZN02677; Sun, 6 Jul 2003 00:23:35 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 19:26:18 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C72@stntexch2.va.neustar.com> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Sat, 5 Jul 2003 19:24:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > Because support for wildcards is a MUST when you implement the NAPTR > record, which ENUM inherits from the DDDS application. If you don't > implement it, you loose. You don't have a DDDS compliant > implementation. > I'm not suggesting that clients refuse to process records with more complex regexp antecedents if they happen to receive them - this is in a section of advice for authors of NAPTR records, not a specification of resolver behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis compliance in any way. [from another mail] > You can have something like this (I think, straight from my head): > > 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > > 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" I had thought that the reason that the reason such examples were removed from rfc2916bis is that we wanted to pass over this issue of partial E.164 numbers in silence. The restriction in the sipping-e164 document basically reinforces this (at a RECOMMENDED level, not as a mandatory statement), but given that this seems to be a controversial matter, perhaps it would be best if we passed over this in silence in the SIPPING document as well. Wildcarding is, I agree, a separable issue. But I guess I am also a little unclear, given the example above, how delegation from 4.e164.arpa to the subdomains works - would there be additional records under 4.e164.arpa besides that NAPTR that indicate delegation? Many of the partial number cases (including the one Martin showed us) do entail some wildcarding, anyway. Jon Peterson NeuStar, Inc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 00:24:50 2003 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 AAA24366 for ; Sun, 6 Jul 2003 00:24:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z14T-0004me-24 for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 00:24:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h664OHtq018384 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 00:24:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z14H-0004g8-2Y; Sun, 06 Jul 2003 00:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z13b-0004cM-SY for enum@optimus.ietf.org; Sun, 06 Jul 2003 00:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24191; Sun, 6 Jul 2003 00:23:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z13Z-0007ce-00; Sun, 06 Jul 2003 00:23:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Z13Y-0007cb-00; Sun, 06 Jul 2003 00:23:20 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 06:23:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h664KjO6009990; Sun, 6 Jul 2003 06:20:45 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 06:22:49 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 06:22:49 +0200 Date: Sun, 6 Jul 2003 06:22:46 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C72@stntexch2.va.neustar.com> Message-Id: <7EDE6628-AF69-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 04:22:49.0496 (UTC) FILETIME=[425AE180:01C34376] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On s=F6ndag, jul 6, 2003, at 02:24 Europe/Stockholm, Peterson, Jon = wrote: >> Because support for wildcards is a MUST when you implement the NAPTR >> record, which ENUM inherits from the DDDS application. If you don't >> implement it, you loose. You don't have a DDDS compliant >> implementation. > > I'm not suggesting that clients refuse to process records with more=20 > complex > regexp antecedents if they happen to receive them - this is in a=20 > section of > advice for authors of NAPTR records, not a specification of resolver > behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis > compliance in any way. Why should they ignore it? They still have to _implement_ it. > [from another mail] >> You can have something like this (I think, straight from my head): >> >> 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> >> 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" > > I had thought that the reason that the reason such examples were=20 > removed > from rfc2916bis is that we wanted to pass over this issue of partial=20= > E.164 > numbers in silence. No, the example was removed because it contained a wildcard in DNS. > The restriction in the sipping-e164 document basically > reinforces this (at a RECOMMENDED level, not as a mandatory=20 > statement), but > given that this seems to be a controversial matter, perhaps it would=20= > be best > if we passed over this in silence in the SIPPING document as well. > > Wildcarding is, I agree, a separable issue. But I guess I am also a=20 > little > unclear, given the example above, how delegation from 4.e164.arpa to=20= > the > subdomains works - would there be additional records under 4.e164.arpa > besides that NAPTR that indicate delegation? Many of the partial = number > cases (including the one Martin showed us) do entail some wildcarding, > anyway. This has _nothing_ to do with partial numbers. Let's then change the example to: 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. foo.bar.example.com. IN NAPTR ....=20 "!^+4(.*)$!sip:9876\1@anotherexample.net!" paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 04:43:37 2003 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 EAA09285 for ; Sun, 6 Jul 2003 04:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z571-0006uR-Hi for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 04:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h668hB34026548 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 04:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z56r-0006sU-VB; Sun, 06 Jul 2003 04:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z56k-0006sA-0X for enum@optimus.ietf.org; Sun, 06 Jul 2003 04:42:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09240; Sun, 6 Jul 2003 04:42:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z56h-0000nj-00; Sun, 06 Jul 2003 04:42:51 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19Z56g-0000nc-00; Sun, 06 Jul 2003 04:42:50 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h668gjb2047952; Sun, 6 Jul 2003 10:42:45 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h668geVd047951; Sun, 6 Jul 2003 10:42:40 +0200 (CEST) Date: Sun, 6 Jul 2003 10:42:40 +0200 From: Marian Durkovic To: enum@ietf.org, sipping@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030706104240.A47655@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > Major problem: 5.3 > "Authors of > records intended to be used for SIP applications SHOULD always use a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." > > I strongly object this. > First, the use of regular expessions is a feature in ENUM and DDDS, > second, there are use cases (e.g. in wildcards) and > third, if there is no-use cases, why is are regular > expression there in > the first place? Hi all, we're heavily using the wildcards in Slovak ENUM trial for pointing all the numbers behind a PBX to the VoIP gateway attached to this PBX. Here is the example: the PBX prefix +421-55555-xxx (number not real) The DNS: $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . Thus when one calls +421-55555-777 the above rule replaces it with sip:1777@foo.sk I really refuse to put 1000 NAPTR records into DNS just to get the same functionality. If someone wants to arrange things in a different way, the exact NAPTR record can still be put into DNS and it overrides the wildcard one. I've seen similar examples in Swedish ENUM trial, so I fully support the objection against the requirement for greedy regexpr. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 09:04:40 2003 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 JAA12445 for ; Sun, 6 Jul 2003 09:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z9Bd-0004xU-4M for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 09:04:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66D4DeV019054 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 09:04:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z9BR-0004wZ-2M; Sun, 06 Jul 2003 09:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z9Ah-0004w8-43 for enum@optimus.ietf.org; Sun, 06 Jul 2003 09:03:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12429; Sun, 6 Jul 2003 09:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z9Af-0001y2-00; Sun, 06 Jul 2003 09:03:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Z9Ae-0001xT-00; Sun, 06 Jul 2003 09:03:12 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 15:02:51 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h66D0VT4014216; Sun, 6 Jul 2003 15:00:33 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 15:01:43 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 15:01:43 +0200 Date: Sun, 6 Jul 2003 15:01:42 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org, sipping@ietf.org To: Marian Durkovic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030706104240.A47655@us.svf.stuba.sk> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 13:01:43.0475 (UTC) FILETIME=[BFA71030:01C343BE] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Can we please keep the discussions about the wildcard in DNS separate =20= from the regular expression in NAPTR as separate as possible? paf On s=F6ndag, jul 6, 2003, at 10:42 Europe/Stockholm, Marian Durkovic =20 wrote: >> Major problem: 5.3 >> "Authors of >> records intended to be used for SIP applications SHOULD always use = =20 >> a >> greedy regexp; no use-cases have been identified today in which a >> different antecedent is necessary." >> >> I strongly object this. >> First, the use of regular expessions is a feature in ENUM and DDDS, >> second, there are use cases (e.g. in wildcards) and >> third, if there is no-use cases, why is are regular >> expression there in >> the first place? > > Hi all, > > we're heavily using the wildcards in Slovak ENUM trial for pointing = =20 > all the > numbers behind a PBX to the VoIP gateway attached to this PBX. Here is = =20 > the > example: > > the PBX prefix +421-55555-xxx (number not real) > > The DNS: > > $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > * IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > Thus when one calls +421-55555-777 the above rule replaces it with > sip:1777@foo.sk > > I really refuse to put 1000 NAPTR records into DNS just to get the =20= > same > functionality. If someone wants to arrange things in a different way, > the exact NAPTR record can still be put into DNS and it overrides the > wildcard one. > > I've seen similar examples in Swedish ENUM trial, so I fully support = =20 > the > objection against the requirement for greedy regexpr. > > > With kind regards, > > M. > > = -----------------------------------------------------------------------=20= > --- > ---- =20= > ---- > ---- Marian Durkovic network manager =20= > ---- > ---- =20= > ---- > ---- Slovak Technical University Tel: +421 2 524 51 301 =20= > ---- > ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 =20= > ---- > ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk =20= > ---- > ---- =20= > ---- > = -----------------------------------------------------------------------=20= > --- > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 12:11:40 2003 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 MAA16450 for ; Sun, 6 Jul 2003 12:11:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZC6c-0001gt-TO for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 12:11:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66GBElP006479 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 12:11:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZC6P-0001bS-Sd; Sun, 06 Jul 2003 12:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZC5s-0001az-W4 for enum@optimus.ietf.org; Sun, 06 Jul 2003 12:10:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16388; Sun, 6 Jul 2003 12:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZC5r-0003Kg-00; Sun, 06 Jul 2003 12:10:27 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZC5q-0003KW-00; Sun, 06 Jul 2003 12:10:26 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h66GAAb2051961; Sun, 6 Jul 2003 18:10:10 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h66GA4sZ051960; Sun, 6 Jul 2003 18:10:04 +0200 (CEST) Date: Sun, 6 Jul 2003 18:10:04 +0200 From: Marian Durkovic To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: enum@ietf.org, sipping@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030706181004.A51884@us.svf.stuba.sk> References: <20030706104240.A47655@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from paf@cisco.com on Sun, Jul 06, 2003 at 03:01:42PM +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by us.svf.stuba.sk id h66GAAb2051961 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: > Can we please keep the discussions about the wildcard in DNS separate =20 > from the regular expression in NAPTR as separate as possible? >=20 > paf I don't think this is fully possible. If you want to use wildcard in DNS, you must use non-greedy regular expression with a subpattern ( ) to extra= ct and reuse the digits matched by the wildcard: $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+42155555(.*)$!sip:1\\1@foo.sk!"= . With kind regards, M. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 12:33:27 2003 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 MAA16767 for ; Sun, 6 Jul 2003 12:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZCRi-0002Py-4Z for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 12:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66GX2GW009290 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 12:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZCRh-0002PL-1A; Sun, 06 Jul 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZCR5-0002OH-7z for enum@optimus.ietf.org; Sun, 06 Jul 2003 12:32:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16732; Sun, 6 Jul 2003 12:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZCR3-0003RB-00; Sun, 06 Jul 2003 12:32:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZCR2-0003R0-00; Sun, 06 Jul 2003 12:32:21 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 18:32:02 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h66GTivJ028000; Sun, 6 Jul 2003 18:29:45 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 18:31:49 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 18:31:49 +0200 Date: Sun, 6 Jul 2003 18:31:48 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org, sipping@ietf.org To: Marian Durkovic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030706181004.A51884@us.svf.stuba.sk> Message-Id: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 16:31:49.0201 (UTC) FILETIME=[19403410:01C343DC] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic=20 wrote: > On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >> Can we please keep the discussions about the wildcard in DNS separate >> from the regular expression in NAPTR as separate as possible? > > I don't think this is fully possible. If you want to use wildcard in=20= > DNS, > you must use non-greedy regular expression with a subpattern ( ) to=20 > extract > and reuse the digits matched by the wildcard: > > $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > * IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . Yes, you are absolutely correct. And one can say dependencies exists in=20= the other direction as well. BUT, today I still see a large number of arguments (especially when=20 looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards=20 in DNS. My point is that that is not enough as an argument for removing the=20 regular expression in the NAPTR for ENUM. It is needed anyway, and I=20 gave an example. You say you don't want a million NAPTR records in your DNS server, and=20= I can understand that given the most common provisioning mechanisms=20 which exists. The IETF do though concentrate on what goes on the wire between hosts,=20= and not so much of how things are inside the host itself. I.e. you might have some DNS software that you can configure given some=20= kind of wildcard, BUT, it will not be a wildcard from a DNS=20 perspective. That is a very very big difference. The wildcard in DNS=20 have many side effects -- most of them today felt being negative. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 18:18:40 2003 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 SAA24662 for ; Sun, 6 Jul 2003 18:18:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHpm-0004IC-Sq for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 18:18:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66MIEJx016496 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 18:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHpZ-0004Gm-Si; Sun, 06 Jul 2003 18:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHpN-0004GG-H9 for enum@optimus.ietf.org; Sun, 06 Jul 2003 18:17:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24633; Sun, 6 Jul 2003 18:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHpK-0004yh-00; Sun, 06 Jul 2003 18:17:46 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19ZHpJ-0004yX-00; Sun, 06 Jul 2003 18:17:45 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 23:16:33 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCA24B; Sun, 6 Jul 2003 23:16:24 +0100 From: "Conroy, Lawrence (SMTP)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Marian Durkovic Cc: enum@ietf.org, sipping@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> References: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> Date: Sun, 6 Jul 2003 23:16:20 +0100 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 6:31 pm +0200 6/7/03, Patrik F=E4ltstr=F6m wrote: >On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic = wrote: > >>On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >>>Can we please keep the discussions about the wildcard in DNS = separate >>>from the regular expression in NAPTR as separate as possible? >> >>I don't think this is fully possible. If you want to use wildcard in = DNS, >>you must use non-greedy regular expression with a subpattern ( ) to = extract >>and reuse the digits matched by the wildcard: >> >>$ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. >>* IN NAPTR 100 10 "u" "E2U+sip" = "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > >Yes, you are absolutely correct. And one can say dependencies exists=20 >in the other direction as well. > >BUT, today I still see a large number of arguments (especially when=20 >looking at DNSSEC) from a pure DNS perspective to _not_ use=20 >wildcards in DNS. > >My point is that that is not enough as an argument for removing the=20 >regular expression in the NAPTR for ENUM. It is needed anyway, and I=20 >gave an example. > >You say you don't want a million NAPTR records in your DNS server,=20 >and I can understand that given the most common provisioning=20 >mechanisms which exists. > >The IETF do though concentrate on what goes on the wire between=20 >hosts, and not so much of how things are inside the host itself. > >I.e. you might have some DNS software that you can configure given=20 >some kind of wildcard, BUT, it will not be a wildcard from a DNS=20 >perspective. That is a very very big difference. The wildcard in DNS=20 >have many side effects -- most of them today felt being negative. > > paf > Hi Patrik, Marian, folks, I'll have one more try. I *did* reset the thread name. Folk must have missed the "Use of=20 Wildcards in ENUM"; this topic is not specific to using ENUM in sip, but...Hey ho. Re. DNS Wildcards - these can exist and can be used, albeit they are = dangerous. What goes over the wire should be a standard DNS response message *as = if the DNS request* had matched the query domain as requested, with several=20 big gotchas to make life interesting. Using a DNS Wildcard is NOT the same as provisioning a whole raft of = similar entries into the DNS server using some sensible software, IMHO; the = effect may be the same, or may not, depending on other entries - that's one reason = why DNS wildcards are risky. Listing the caveats in DNS wildcard use for ENUM seems like a good idea = to me, as, at first, they look like they are very useful. This means that = there WILL be these in ENUM DNS server configurations, so at least a "here's some = hints on detecting and debugging problems with these" would be useful. Yes, it's a standard DNS issue and should be in the FAQ, but they look = like a natural for ENUM with number ranges being reflected as sub-domains, = so I suspect they WILL be an issue that ENUM folk will hit more than most. BTW, I will have a range that directs to an attendant, and so could be = done with a DNS wildcard *without* a non-greedy regexp - these ARE separable = issues. all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 6 18:27:27 2003 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 SAA24838 for ; Sun, 6 Jul 2003 18:27:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHyI-0004bw-5t for enum-archive@odin.ietf.org; Sun, 06 Jul 2003 18:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66MR2Ew017705 for enum-archive@odin.ietf.org; Sun, 6 Jul 2003 18:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHyH-0004b7-1R; Sun, 06 Jul 2003 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHyC-0004aq-LE for enum@optimus.ietf.org; Sun, 06 Jul 2003 18:26:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24828 for ; Sun, 6 Jul 2003 18:26:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHy9-000527-00 for enum@ietf.org; Sun, 06 Jul 2003 18:26:53 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19ZHy9-00051y-00 for enum@ietf.org; Sun, 06 Jul 2003 18:26:53 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 23:26:23 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCA241; Sun, 6 Jul 2003 23:26:17 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> Date: Sun, 6 Jul 2003 23:26:13 +0100 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Just now I said: >BTW, I will have a range that directs to an attendant, and so could be done >with a DNS wildcard *without* a non-greedy regexp - these ARE >separable issues. What I actually meant to say was: BTW, I will have a range that directs to an attendant, and so could be done with a DNS wildcard *without* a greedy regexp - these ARE separable issues. Time for bed. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 04:44:48 2003 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 EAA17516 for ; Mon, 7 Jul 2003 04:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRbg-0006D3-4m for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 04:44:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h678iKaQ023870 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 04:44:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRbO-0006CL-0i; Mon, 07 Jul 2003 04:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRaP-0006BY-7O for enum@optimus.ietf.org; Mon, 07 Jul 2003 04:43:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17480; Mon, 7 Jul 2003 04:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRaM-0002CB-00; Mon, 07 Jul 2003 04:42:58 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19ZRaL-0002By-00; Mon, 07 Jul 2003 04:42:57 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jul 2003 10:42:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A1813CC@inno-exchange.innovaphone.com> Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcND3EmKNRv3Fc92SYa72PtJJYZlegAgkvfQ From: "Martin Streller" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Marian Durkovic" Cc: , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Patrik, >The wildcard in DNS=20 >have many side effects -- most of them today felt being negative. you may admit such a statement is a bit vague and nebulous. Given an example like Marian's or mine - what are the definite=20 side effects that you feel negative about ? Martin -----Urspr=FCngliche Nachricht----- Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] Gesendet: Sonntag, 6. Juli 2003 18:32 An: Marian Durkovic Cc: enum@ietf.org; sipping@ietf.org Betreff: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic=20 wrote: > On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >> Can we please keep the discussions about the wildcard in DNS separate >> from the regular expression in NAPTR as separate as possible? > > I don't think this is fully possible. If you want to use wildcard in=20 > DNS, > you must use non-greedy regular expression with a subpattern ( ) to=20 > extract > and reuse the digits matched by the wildcard: > > $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > * IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . Yes, you are absolutely correct. And one can say dependencies exists in=20 the other direction as well. BUT, today I still see a large number of arguments (especially when=20 looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards=20 in DNS. My point is that that is not enough as an argument for removing the=20 regular expression in the NAPTR for ENUM. It is needed anyway, and I=20 gave an example. You say you don't want a million NAPTR records in your DNS server, and=20 I can understand that given the most common provisioning mechanisms=20 which exists. The IETF do though concentrate on what goes on the wire between hosts,=20 and not so much of how things are inside the host itself. I.e. you might have some DNS software that you can configure given some=20 kind of wildcard, BUT, it will not be a wildcard from a DNS=20 perspective. That is a very very big difference. The wildcard in DNS=20 have many side effects -- most of them today felt being negative. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 05:10:37 2003 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 FAA18004 for ; Mon, 7 Jul 2003 05:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZS0g-0007I7-Hm for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 05:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h679AAVL028007 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 05:10:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZS0X-0007H9-Ng; Mon, 07 Jul 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRzm-0007G6-Lh for enum@optimus.ietf.org; Mon, 07 Jul 2003 05:09:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17951 for ; Mon, 7 Jul 2003 05:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRzj-0002Sl-00 for enum@ietf.org; Mon, 07 Jul 2003 05:09:11 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19ZRzi-0002Rq-00 for enum@ietf.org; Mon, 07 Jul 2003 05:09:10 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h6798UL4003029; Mon, 7 Jul 2003 11:08:31 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307070908.h6798UL4003029@bartok.sidn.nl> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Sat, 05 Jul 2003 05:20:21 +0200. <9C7A26E8-AE97-11D7-BE0E-000A959CF516@cisco.com> Date: Mon, 07 Jul 2003 11:08:30 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Yes, but _if_ the DNS community say "using wildcards in DNS is ok" _then_ ENUM will be able to use it fully as we inherit the regexp in the DDDS specification. With my DNS hat on, I would still though say "if you use wildcards in DNS, you really really really must understand the implications, so you better try to solve the problem you have in some other way first". I think we are in violent agreement here. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 05:36:29 2003 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 FAA18687 for ; Mon, 7 Jul 2003 05:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSPi-0008CD-CZ for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 05:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h679a21h031499 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 05:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSPg-0008Ba-T3; Mon, 07 Jul 2003 05:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSPT-0008BC-Fi for enum@optimus.ietf.org; Mon, 07 Jul 2003 05:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18660; Mon, 7 Jul 2003 05:35:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZSPQ-0002dN-00; Mon, 07 Jul 2003 05:35:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZSPP-0002dK-00; Mon, 07 Jul 2003 05:35:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2003 11:35:25 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h679X70Y015945; Mon, 7 Jul 2003 11:33:08 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 11:35:12 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 11:35:12 +0200 Date: Mon, 7 Jul 2003 11:35:09 +0200 Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Marian Durkovic" , , To: "Martin Streller" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0E6CC1D4D38A5742930CE896A653477A1813CC@inno-exchange.innovaphone.com> Message-Id: <4CF9C507-B05E-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 07 Jul 2003 09:35:12.0282 (UTC) FILETIME=[1056CFA0:01C3446B] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On m=E5ndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller=20 wrote: >> The wildcard in DNS >> have many side effects -- most of them today felt being negative. > > you may admit such a statement is a bit vague and nebulous. > > Given an example like Marian's or mine - what are the definite > side effects that you feel negative about ? (1) If you have an owner which have a CNAME, you can not have any other=20= RR with the same owner. Many many people fail on this (for example,=20 they add an MX record). (2) The implications with DNSSEC is not known in enough detail.=20 Especially when looking at negative caching. Yes, compared to some 6-12=20= months ago, there are ideas on how it might work, but the proposal is=20 still to run wildcards in either a delegated zone which is not secure,=20= or you synthesize your records, which in turn means you need to have=20 the private key online. (3) It is easy to forget the wildcard when you later need to delegate=20 something, and understand the implications (together with (1) above). But, the largest problems are with (1) and (2). As DNSSEC is important for ENUM, I rather stay away from wildcards. The=20= wildcards _can_ be simulated by either generating many records, or by=20 having a DNS server which synthesizes the records. Another problem when you do ENUM is that there will be responses if=20 someone query for for example: NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR and in the DNS I have *.1.2.3.4.6.4.e164.arpa. IN NAPTR .... I don't like that. You might want to store other RR types with similar=20= names in the same hierarchy, for example SRV records (which Microsoft=20 Active Directory uses heavily) or whatever. paf > > Martin > > -----Urspr=FCngliche Nachricht----- > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Gesendet: Sonntag, 6. Juli 2003 18:32 > An: Marian Durkovic > Cc: enum@ietf.org; sipping@ietf.org > Betreff: Re: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.t xt > > > On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic > wrote: > >> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >>> Can we please keep the discussions about the wildcard in DNS = separate >>> from the regular expression in NAPTR as separate as possible? >> >> I don't think this is fully possible. If you want to use wildcard in >> DNS, >> you must use non-greedy regular expression with a subpattern ( ) to >> extract >> and reuse the digits matched by the wildcard: >> >> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. >> * IN NAPTR 100 10 "u" "E2U+sip" >> "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > Yes, you are absolutely correct. And one can say dependencies exists = in > the other direction as well. > > BUT, today I still see a large number of arguments (especially when > looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards > in DNS. > > My point is that that is not enough as an argument for removing the > regular expression in the NAPTR for ENUM. It is needed anyway, and I > gave an example. > > You say you don't want a million NAPTR records in your DNS server, and > I can understand that given the most common provisioning mechanisms > which exists. > > The IETF do though concentrate on what goes on the wire between hosts, > and not so much of how things are inside the host itself. > > I.e. you might have some DNS software that you can configure given = some > kind of wildcard, BUT, it will not be a wildcard from a DNS > perspective. That is a very very big difference. The wildcard in DNS > have many side effects -- most of them today felt being negative. > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 08:53:00 2003 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 IAA23379 for ; Mon, 7 Jul 2003 08:53:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVTs-0007iw-8k for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 08:52:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67CqWKr029686 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 08:52:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVTM-0007Z9-S2; Mon, 07 Jul 2003 08:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVT0-0007Yj-UT for enum@optimus.ietf.org; Mon, 07 Jul 2003 08:51:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23314; Mon, 7 Jul 2003 08:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZVSz-0003tV-00; Mon, 07 Jul 2003 08:51:37 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZVSy-0003se-00; Mon, 07 Jul 2003 08:51:36 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h67CpIb2077472; Mon, 7 Jul 2003 14:51:18 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h67CpDZC077471; Mon, 7 Jul 2003 14:51:13 +0200 (CEST) Date: Mon, 7 Jul 2003 14:51:13 +0200 From: Marian Durkovic To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030707145113.A75121@us.svf.stuba.sk> References: <0E6CC1D4D38A5742930CE896A653477A1813CC@inno-exchange.innovaphone.com> <4CF9C507-B05E-11D7-BE0E-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4CF9C507-B05E-11D7-BE0E-000A959CF516@cisco.com>; from paf@cisco.com on Mon, Jul 07, 2003 at 11:35:09AM +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by us.svf.stuba.sk id h67CpIb2077472 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable OK, but all this still translates to me as "use with care" and not as=20 "don't use at all". Sure the DNS admins should be aware of the issues described in RFC1912. Regarding the DNSSEC, ENUM could perhaps apply the=20 attitude described in draft-ietf-dnsext-dns-threats-03.txt: ...since the alternative of giving up wildcards entirely is not=20 practical due to widespread use, we are going to have to live with=20 wildcards, and the question just becomes one of whether or not the=20 proposed optimizations would make DNSSEC's wildcard proof mechanisms= =20 more or less fragile. Anyway, the original topic was, that we all should always use a greedy regexpr which is (not only but also) due to possible use in wildcards and/or in synthesizing DNS servers certainly not a good idea. With kind regards, M. =20 On Mon, Jul 07, 2003 at 11:35:09AM +0200, Patrik F=E4ltstr=F6m wrote: > On m=E5ndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller=20 > wrote: >=20 > >> The wildcard in DNS > >> have many side effects -- most of them today felt being negative. > > > > you may admit such a statement is a bit vague and nebulous. > > > > Given an example like Marian's or mine - what are the definite > > side effects that you feel negative about ? >=20 > (1) If you have an owner which have a CNAME, you can not have any other= =20 > RR with the same owner. Many many people fail on this (for example,=20 > they add an MX record). > (2) The implications with DNSSEC is not known in enough detail.=20 > Especially when looking at negative caching. Yes, compared to some 6-12= =20 > months ago, there are ideas on how it might work, but the proposal is=20 > still to run wildcards in either a delegated zone which is not secure,=20 > or you synthesize your records, which in turn means you need to have=20 > the private key online. > (3) It is easy to forget the wildcard when you later need to delegate=20 > something, and understand the implications (together with (1) above). >=20 > But, the largest problems are with (1) and (2). >=20 > As DNSSEC is important for ENUM, I rather stay away from wildcards. The= =20 > wildcards _can_ be simulated by either generating many records, or by=20 > having a DNS server which synthesizes the records. >=20 > Another problem when you do ENUM is that there will be responses if=20 > someone query for for example: >=20 > NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR >=20 > and in the DNS I have >=20 > *.1.2.3.4.6.4.e164.arpa. IN NAPTR .... >=20 > I don't like that. You might want to store other RR types with similar=20 > names in the same hierarchy, for example SRV records (which Microsoft=20 > Active Directory uses heavily) or whatever. >=20 > paf >=20 >=20 > > > > Martin > > > > -----Urspr=FCngliche Nachricht----- > > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > > Gesendet: Sonntag, 6. Juli 2003 18:32 > > An: Marian Durkovic > > Cc: enum@ietf.org; sipping@ietf.org > > Betreff: Re: [Enum] Fwd: [Sipping] I-D > > ACTION:draft-ietf-sipping-e164-03.t xt > > > > > > On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic > > wrote: > > > >> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote= : > >>> Can we please keep the discussions about the wildcard in DNS separa= te > >>> from the regular expression in NAPTR as separate as possible? > >> > >> I don't think this is fully possible. If you want to use wildcard in > >> DNS, > >> you must use non-greedy regular expression with a subpattern ( ) to > >> extract > >> and reuse the digits matched by the wildcard: > >> > >> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > >> * IN NAPTR 100 10 "u" "E2U+sip" > >> "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > > > Yes, you are absolutely correct. And one can say dependencies exists = in > > the other direction as well. > > > > BUT, today I still see a large number of arguments (especially when > > looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards > > in DNS. > > > > My point is that that is not enough as an argument for removing the > > regular expression in the NAPTR for ENUM. It is needed anyway, and I > > gave an example. > > > > You say you don't want a million NAPTR records in your DNS server, an= d > > I can understand that given the most common provisioning mechanisms > > which exists. > > > > The IETF do though concentrate on what goes on the wire between hosts= , > > and not so much of how things are inside the host itself. > > > > I.e. you might have some DNS software that you can configure given so= me > > kind of wildcard, BUT, it will not be a wildcard from a DNS > > perspective. That is a very very big difference. The wildcard in DNS > > have many side effects -- most of them today felt being negative. > > > > paf > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 10:21:38 2003 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 KAA27125 for ; Mon, 7 Jul 2003 10:21:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWrf-0003MK-5r for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 10:21:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67ELBFK012866 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 10:21:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWrV-0003Kh-47; Mon, 07 Jul 2003 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWrI-0003KH-Cg for enum@optimus.ietf.org; Mon, 07 Jul 2003 10:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27093; Mon, 7 Jul 2003 10:20:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWrG-0004gf-00; Mon, 07 Jul 2003 10:20:46 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZWrF-0004gO-00; Mon, 07 Jul 2003 10:20:45 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 18944137F16; Mon, 7 Jul 2003 07:20:06 -0700 (PDT) To: Marian Durkovic Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org, sipping@ietf.org Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Marian Durkovic of "Mon, 07 Jul 2003 14:51:13 +0200." <20030707145113.A75121@us.svf.stuba.sk> Date: Mon, 07 Jul 2003 07:20:06 -0700 Message-ID: <1936.1057587606@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> OK, but all this still translates to me as "use with care" Marian> and not as "don't use at all". Sure the DNS admins should Marian> be aware of the issues described in RFC!912. Regarding the Marian> DNSSEC, ENUM could perhaps apply the attitude described in Marian> draft-ietf-dnsext-dns-threats-03.txt: I strongly disagree with you. DNS wildcards are at best a last resort. They should only be considered when it is proven there is no other viable alternative. That's my take on what Patrik has said. Most clueful DNS people share that perspective. [Or, like me, they take a more extreme position and say wildcard RRs are evil and to be avoided at all costs.] So far, it's not been demonstrated why this proposed wildcard RR is essential or why there are no other viable options. The issues surrounding DNSSEC are just one part of the wildcarding problem. Until these are fully understood, it would be prudent not to advocate or deploy ENUM solutions/specifications that depended on wildcard RRs. We know DNSSEC *is* going to figure in ENUM one day. Having to cope with the signing (or non-signing) of wildcards is too much of a leap into the dark. This needs to be worked out and documented. It also looks to me like the wildcard NAPTR RR has been proposed here to kludge around name server provisioning issues. If that's the case, wouldn't it be better to solve the underlying problem? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 10:34:30 2003 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 KAA27629 for ; Mon, 7 Jul 2003 10:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX47-00041h-4w for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 10:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67EY3YM015473 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 10:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX44-000416-PS; Mon, 07 Jul 2003 10:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX3e-00040W-7H for enum@optimus.ietf.org; Mon, 07 Jul 2003 10:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27580; Mon, 7 Jul 2003 10:33:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZX3b-0004pn-00; Mon, 07 Jul 2003 10:33:31 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19ZX3a-0004p5-00; Mon, 07 Jul 2003 10:33:30 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h67EWwc12670; Mon, 7 Jul 2003 14:32:58 GMT Message-Id: <5.2.0.9.2.20030703095442.03365c68@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Jul 2003 09:57:05 -0400 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Enum] FINAL Agenda ENUM WG IETF 57 Vienna Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable MONDAY, July 14, 2003 1130-1300 Break 1300-1500 Afternoon Sessions I Hall LM APP xmpp Extensible Messaging and Presence Protocol WG Hall F2 GEN coach Comprehensive apprOACH to quality BOF Hall E2 INT pana Protocol for carrying Authentication for Network Access WG Hall F1 OPS multi6 Site Multihoming in IPv6 WG Hall NO RTG forces Forwarding and Control Element Separation WG Hall GH SUB tewg Internet Traffic Engineering WG Hall IK TSV enum Telephone Number Mapping WG IETF 57 Vienna Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction =85 VOLUNTEERS WANTED ! or Else ... . 1. Applicability Statement of CRISP work to ENUM - 20 Min Title : IRIS - An ENUM Registry (ereg) Type for the= Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-00.txt Pages : 34 Date : 2003-6-24 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt 2. Security and Privacy Considerations Shockey - Morris 20 min Draft URL To be Published ... 3. Review of National ENUM Trials ... 10 Min or suchEach UK - Jim Reid Austria - Richard Stastny Korea - Jeonghyun Lee Sweden - Patrik Faltstrom 4. WG next steps 20 Min : Jim Reid , Richard Stastny etc. 5. General Discussion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 10:35:30 2003 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 KAA27691 for ; Mon, 7 Jul 2003 10:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX54-0004BY-GX for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 10:35:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67EZ2Jp016070 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 10:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX54-0004Ao-6i; Mon, 07 Jul 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX4u-00049k-Fi for enum@optimus.ietf.org; Mon, 07 Jul 2003 10:34:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27656; Mon, 7 Jul 2003 10:34:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZX4s-0004rC-00; Mon, 07 Jul 2003 10:34:50 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19ZX4r-0004qj-00; Mon, 07 Jul 2003 10:34:49 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h67EYHc12705; Mon, 7 Jul 2003 14:34:17 GMT Message-Id: <5.2.0.9.2.20030627110328.01ba79a0@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Jul 2003 10:34:53 -0400 To: iesg-secretary@ietf.org From: Richard Shockey Cc: paf@cisco.com, mankin@psg.com, jon.peterson@neustar.biz, enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Request to Publish : draft-ietf-enum-msg-00.txt, draft-ietf-enum-webft-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a request for publication of two IETF ENUM WG working group documents. WG last call on these documents concluded on June 27th ... The documents listed below are being proposed for Standards Track RFC. Status- Proposed Standard These documents are ENUM Working Group products, which have been extensively discussed during 2003. Title : Registration for enumservices of group messages Author(s) : R. Brandner et al. Filename : draft-ietf-enum-msg-00.txt Pages : 17 Date : 2003-6-16 This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-00.txt ################# Title : Registration for enumservices web and ft Author(s) : R. Brandner et al. Filename : draft-ietf-enum-webft-00.txt Pages : 13 Date : 2003-6-16 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. Specifically, the 'enumservices' registered with this document are 'web' and 'ft' using the URI schemes 'http:', 'https:' and 'ftp:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 10:40:30 2003 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 KAA27953 for ; Mon, 7 Jul 2003 10:40:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX9v-0004eN-2V for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 10:40:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ee30Y017843 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 10:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX9t-0004dH-6m; Mon, 07 Jul 2003 10:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX9K-0004cF-D9 for enum@optimus.ietf.org; Mon, 07 Jul 2003 10:39:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27900; Mon, 7 Jul 2003 10:39:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZX9H-0004w8-00; Mon, 07 Jul 2003 10:39:24 -0400 Received: from smtp-05.inode.at ([62.99.194.7] helo=smtp.inode.at) by ietf-mx with esmtp (Exim 4.12) id 19ZX9H-0004w4-00; Mon, 07 Jul 2003 10:39:23 -0400 Received: from [62.99.233.53] (port=29464 helo=mah9.eunet.at) by smtp.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 19ZX94-0001i6-00; Mon, 07 Jul 2003 16:39:10 +0200 Message-Id: <5.2.0.9.2.20030707162825.01cd1cd8@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Jul 2003 16:38:46 +0200 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Marian Durkovic From: Michael Haberler Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Cc: enum@ietf.org, sipping@ietf.org In-Reply-To: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> References: <20030706181004.A51884@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-59E41861; boundary="=======552D709D=======" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======552D709D======= Content-Type: text/plain; x-avg-checked=avg-ok-59E41861; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable At 18:31 06.07.2003 +0200, Patrik F=E4ltstr=F6m wrote: The IETF do though concentrate on what goes on the wire between hosts, and= =20 not so much of how things are inside the host itself. >I.e. you might have some DNS software that you can configure given some=20 >kind of wildcard, BUT, it will not be a wildcard from a DNS perspective.=20 >That is a very very big difference. The wildcard in DNS have many side=20 >effects -- most of them today felt being negative. that is quite an elegant idea - if I get you right you propose to PROVISION= =20 it as a wildcard, have special code interpret it and give specific answers= =20 if the wildcard would match in the status ante scenario however - do i get this right that this will break zone transfer as we know= =20 it? and I'm fuzzy what the DNSsec implications are - I would assume you=20 cant sign a record which isnt in the zone Or do you propose to have a wildcard in the zone, and have the server=20 interpret it differently - i.e giving a matching non-wildcard response? those with working ENUM trials;) have a strong interest in a good solution= =20 of this problem (enumeration of number space !=3D good) if we can reach consensus as to how to provision this and what the=20 semantics are, we might have a non-problem afterall and we instead could go= =20 home and build the damn thing maybe we should just cook up a syntax for a bind9 config file and a= semantics -Michael --=======552D709D=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 10:55:35 2003 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 KAA28438 for ; Mon, 7 Jul 2003 10:55:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXOW-00056S-S1 for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 10:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Et8vX019585 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 10:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXOP-00055I-Hu; Mon, 07 Jul 2003 10:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXOG-00054i-07 for enum@optimus.ietf.org; Mon, 07 Jul 2003 10:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28418; Mon, 7 Jul 2003 10:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXOD-00056m-00; Mon, 07 Jul 2003 10:54:49 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZXOC-00056f-00; Mon, 07 Jul 2003 10:54:48 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 4DE77137F16; Mon, 7 Jul 2003 07:54:18 -0700 (PDT) To: Michael Haberler Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Marian Durkovic , enum@ietf.org, sipping@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Michael Haberler of "Mon, 07 Jul 2003 16:38:46 +0200." <5.2.0.9.2.20030707162825.01cd1cd8@mail.inode.at> Date: Mon, 07 Jul 2003 07:54:18 -0700 Message-ID: <2281.1057589658@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Michael" == Michael Haberler writes: Michael> maybe we should just cook up a syntax for a bind9 config Michael> file and a= semantics Please don't confuse the DNS protocol with an implementation of that protocol. In all probability a "solution" based around BIND9 is not likely to be practical in the long run. If/when ENUM takes off, the datasets are going to be 1-2 orders of magnitude bigger than what's in the DNS today, maybe more. [Compare the number of registrations or domain names under .at with the number of phones in Austria for example.] Managing and provisioning these sorts of datasets with BIND9 text files will be very, very painful. They may even be unworkable. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 11:04:28 2003 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 LAA28877 for ; Mon, 7 Jul 2003 11:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXX8-0005hp-BJ for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 11:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67F42Qj021903 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 11:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXX6-0005gl-O7; Mon, 07 Jul 2003 11:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXWL-0005eJ-2F for enum@optimus.ietf.org; Mon, 07 Jul 2003 11:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28820; Mon, 7 Jul 2003 11:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXWI-0005CR-00; Mon, 07 Jul 2003 11:03:10 -0400 Received: from smtp-01.inode.at ([62.99.194.3] helo=smtp.inode.at) by ietf-mx with esmtp (Exim 4.12) id 19ZXWH-0005CO-00; Mon, 07 Jul 2003 11:03:09 -0400 Received: from [62.99.233.53] (port=29516 helo=mah9.eunet.at) by smtp.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 19ZXW9-0006CO-00; Mon, 07 Jul 2003 17:03:01 +0200 Message-Id: <5.2.0.9.2.20030707165618.01ca3900@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 07 Jul 2003 17:02:57 +0200 To: Jim Reid From: Michael Haberler Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Marian Durkovic , enum@ietf.org, sipping@ietf.org In-Reply-To: <2281.1057589658@shell.nominum.com> References: <5.2.0.9.2.20030707162825.01cd1cd8@mail.inode.at> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-59E41861; boundary="=======5006470F=======" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======5006470F======= Content-Type: text/plain; x-avg-checked=avg-ok-59E41861; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit did that math - that's why we are not running bind9 for 3.4.e164.arpa; we run a server straight off a database I really dont care about the vehicle, I just assumed a bind9 config option would serve well as an operational specification and guideline for the rest of us So what would you propose instead? -Michael At 07:54 07.07.2003 -0700, you wrote: > >>>>> "Michael" == Michael Haberler writes: > > Michael> maybe we should just cook up a syntax for a bind9 config > Michael> file and a= semantics > >Please don't confuse the DNS protocol with an implementation of that >protocol. In all probability a "solution" based around BIND9 is not >likely to be practical in the long run. If/when ENUM takes off, the >datasets are going to be 1-2 orders of magnitude bigger than what's in >the DNS today, maybe more. [Compare the number of registrations or >domain names under .at with the number of phones in Austria for >example.] Managing and provisioning these sorts of datasets with BIND9 >text files will be very, very painful. They may even be unworkable. --=======5006470F=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 11:19:33 2003 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 LAA29560 for ; Mon, 7 Jul 2003 11:19:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXlh-00071Q-5s for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 11:19:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67FJ5UA026986 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 11:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXld-00070b-8U; Mon, 07 Jul 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXlR-0006zi-Vm for enum@optimus.ietf.org; Mon, 07 Jul 2003 11:18:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29504; Mon, 7 Jul 2003 11:18:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXlR-0005QL-00; Mon, 07 Jul 2003 11:18:49 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19ZXlQ-0005QH-00; Mon, 07 Jul 2003 11:18:48 -0400 content-class: urn:content-classes:message Subject: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jul 2003 17:18:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A2F24C7@inno-exchange.innovaphone.com> Thread-Topic: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcNEaw3S4ToX/h4pS+a9ebKE39reqwAMEcgw From: "Martin Streller" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Marian Durkovic" , , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks, for the facts (1) Ok a problem, but wouldn't disturb in my living case/example (2) Well, it can only be a fair move to foster ongoing discussion among the DNSSEC group about this issue. (3) ff.=20 - I'd favour the record-synthesizing DNS server.=20 I guess such a gizmo at customer/corporate premises would also need to=20 be dnssec aware ? Or could I ship around this ? Pls. clarify. - Yes, the query string containing a Not-A-Number sublabel may happen = but wouldn't cause damage beyond wasted bandwidth. - If you want to stay away from wildcards you should at least note that = it represents a cheap ENUM entry for low. Intricate provisioning means costs while = we're all living in a consolidating world. Martin -----Urspr=FCngliche Nachricht----- Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] Gesendet: Montag, 7. Juli 2003 11:35 An: Martin Streller Cc: Marian Durkovic; enum@ietf.org; sipping@ietf.org Betreff: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt On m=E5ndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller=20 wrote: >> The wildcard in DNS >> have many side effects -- most of them today felt being negative. > > you may admit such a statement is a bit vague and nebulous. > > Given an example like Marian's or mine - what are the definite > side effects that you feel negative about ? (1) If you have an owner which have a CNAME, you can not have any other=20 RR with the same owner. Many many people fail on this (for example,=20 they add an MX record). (2) The implications with DNSSEC is not known in enough detail.=20 Especially when looking at negative caching. Yes, compared to some 6-12=20 months ago, there are ideas on how it might work, but the proposal is=20 still to run wildcards in either a delegated zone which is not secure,=20 or you synthesize your records, which in turn means you need to have=20 the private key online. (3) It is easy to forget the wildcard when you later need to delegate=20 something, and understand the implications (together with (1) above). But, the largest problems are with (1) and (2). As DNSSEC is important for ENUM, I rather stay away from wildcards. The=20 wildcards _can_ be simulated by either generating many records, or by=20 having a DNS server which synthesizes the records. Another problem when you do ENUM is that there will be responses if=20 someone query for for example: NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR and in the DNS I have *.1.2.3.4.6.4.e164.arpa. IN NAPTR .... I don't like that. You might want to store other RR types with similar=20 names in the same hierarchy, for example SRV records (which Microsoft=20 Active Directory uses heavily) or whatever. paf > > Martin > > -----Urspr=FCngliche Nachricht----- > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Gesendet: Sonntag, 6. Juli 2003 18:32 > An: Marian Durkovic > Cc: enum@ietf.org; sipping@ietf.org > Betreff: Re: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.t xt > > > On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic > wrote: > >> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >>> Can we please keep the discussions about the wildcard in DNS = separate >>> from the regular expression in NAPTR as separate as possible? >> >> I don't think this is fully possible. If you want to use wildcard in >> DNS, >> you must use non-greedy regular expression with a subpattern ( ) to >> extract >> and reuse the digits matched by the wildcard: >> >> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. >> * IN NAPTR 100 10 "u" "E2U+sip" >> "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > Yes, you are absolutely correct. And one can say dependencies exists = in > the other direction as well. > > BUT, today I still see a large number of arguments (especially when > looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards > in DNS. > > My point is that that is not enough as an argument for removing the > regular expression in the NAPTR for ENUM. It is needed anyway, and I > gave an example. > > You say you don't want a million NAPTR records in your DNS server, and > I can understand that given the most common provisioning mechanisms > which exists. > > The IETF do though concentrate on what goes on the wire between hosts, > and not so much of how things are inside the host itself. > > I.e. you might have some DNS software that you can configure given = some > kind of wildcard, BUT, it will not be a wildcard from a DNS > perspective. That is a very very big difference. The wildcard in DNS > have many side effects -- most of them today felt being negative. > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 11:26:34 2003 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 LAA29804 for ; Mon, 7 Jul 2003 11:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXsU-0007MK-Ao for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 11:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67FQ61n028256 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 11:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXsP-0007LA-HH; Mon, 07 Jul 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXre-0007Ki-TV for enum@optimus.ietf.org; Mon, 07 Jul 2003 11:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29779; Mon, 7 Jul 2003 11:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXrd-0005XS-00; Mon, 07 Jul 2003 11:25:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZXrd-0005XB-00; Mon, 07 Jul 2003 11:25:13 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2003 17:24:52 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h67FMV7h004646; Mon, 7 Jul 2003 17:22:36 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 17:24:37 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 17:24:37 +0200 Date: Mon, 7 Jul 2003 17:24:34 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Marian Durkovic , enum@ietf.org, sipping@ietf.org To: Michael Haberler From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5.2.0.9.2.20030707162825.01cd1cd8@mail.inode.at> Message-Id: <1D097868-B08F-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 07 Jul 2003 15:24:37.0613 (UTC) FILETIME=[E0A671D0:01C3449B] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On m=E5ndag, jul 7, 2003, at 16:38 Europe/Stockholm, Michael Haberler=20 wrote: > however - do i get this right that this will break zone transfer as we=20= > know it? and I'm fuzzy what the DNSsec implications are - I would=20 > assume you cant sign a record which isnt in the zone The proposal I saw talked about using a wildcard in DNS, which is a=20 very very special thing in the DNS specification. What I saw the=20 proposal talked about was a "simple" way of specifying what to do with=20= not all possible labels in a zone (which DNS wildcard help with) but=20 instead what happens with the labels which matches the syntax of an=20 ENUM NAPTR. (Just digits, one digit in each label. Those are two very different things. And, what you talk about above are some of the issues with Wildcards. What I said was not that wildcards in dns should not be used, but, as=20 Jim says, it should be as the absolute last resort, and the one=20 choosing to use wildcards must know about the implications. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 11:53:01 2003 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 LAA00851 for ; Mon, 7 Jul 2003 11:53:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYI5-0000Cl-6S for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 11:52:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67FqXO1000781 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 11:52:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYHZ-0000Bm-14; Mon, 07 Jul 2003 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYHI-0000AI-Ae for enum@optimus.ietf.org; Mon, 07 Jul 2003 11:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00760; Mon, 7 Jul 2003 11:51:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYHH-0005os-00; Mon, 07 Jul 2003 11:51:43 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZYHF-0005o6-00; Mon, 07 Jul 2003 11:51:42 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2003 17:51:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h67Fmj3g010278; Mon, 7 Jul 2003 17:48:46 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 17:50:47 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 17:50:46 +0200 Date: Mon, 7 Jul 2003 17:50:44 +0200 Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Marian Durkovic" , , To: "Martin Streller" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0E6CC1D4D38A5742930CE896A653477A2F24C7@inno-exchange.innovaphone.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 07 Jul 2003 15:50:47.0023 (UTC) FILETIME=[881767F0:01C3449F] Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On m=E5ndag, jul 7, 2003, at 17:18 Europe/Stockholm, Martin Streller=20 wrote: > (1) Ok a problem, but wouldn't disturb in my living case/example Good, just remember this... ;-) > (2) Well, it can only be a fair move to foster ongoing discussion > among the DNSSEC group about this issue. Yes, and there _IS_ a discussion going. I do though think DNSSEC might=20= be deployable before we know all details of wildcards, DNSSEC etc=20 together. It would be sad if you can not deploy DNSSEC at that date for=20= your zone just because of the wildcard (or, you deploy and things go=20 *poof*). > (3) ff. > - I'd favour the record-synthesizing DNS server. > I guess such a gizmo at customer/corporate premises would also need to > be dnssec aware ? Or could I ship around this ? Pls. clarify. It can happen in two ways: - The records are created for certain queries when the query arrive at=20= the server - The records are created by the provisioning system Because of DNSSEC, I would prefer the second, because otherwise you=20 need to have the private key signing the zone on the host which=20 responds to DNS queries, and that is not something _I_ would like to=20 have. > - Yes, the query string containing a Not-A-Number sublabel may happen=20= > but wouldn't > cause damage beyond wasted bandwidth. > > - If you want to stay away from wildcards you should at least note=20 > that it represents > a cheap ENUM entry for low. Intricate provisioning means costs while=20= > we're all living in > a consolidating world. Absolutely. As I said, the one using wildcards should use it as a last=20= resort. That can be implementation issues, cost issues or whatever. One=20= should spend some time investigating _why_ wildcards are needed. If one=20= have an answer, fine. One good control question might be: "Let's use wildcards today. If DNSSEC is not possible together with=20 wildcards, will we do DNSSEC or wildcards when that day comes?" Different people have different answers. paf > > Martin > > -----Urspr=FCngliche Nachricht----- > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Gesendet: Montag, 7. Juli 2003 11:35 > An: Martin Streller > Cc: Marian Durkovic; enum@ietf.org; sipping@ietf.org > Betreff: Re: AW: [Enum] Fwd: [Sipping] I-D > ACTION:draft-ietf-sipping-e164-03.t xt > > > On m=E5ndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller > wrote: > >>> The wildcard in DNS >>> have many side effects -- most of them today felt being negative. >> >> you may admit such a statement is a bit vague and nebulous. >> >> Given an example like Marian's or mine - what are the definite >> side effects that you feel negative about ? > > (1) If you have an owner which have a CNAME, you can not have any = other > RR with the same owner. Many many people fail on this (for example, > they add an MX record). > (2) The implications with DNSSEC is not known in enough detail. > Especially when looking at negative caching. Yes, compared to some = 6-12 > months ago, there are ideas on how it might work, but the proposal is > still to run wildcards in either a delegated zone which is not secure, > or you synthesize your records, which in turn means you need to have > the private key online. > (3) It is easy to forget the wildcard when you later need to delegate > something, and understand the implications (together with (1) above). > > But, the largest problems are with (1) and (2). > > As DNSSEC is important for ENUM, I rather stay away from wildcards. = The > wildcards _can_ be simulated by either generating many records, or by > having a DNS server which synthesizes the records. > > Another problem when you do ENUM is that there will be responses if > someone query for for example: > > NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR > > and in the DNS I have > > *.1.2.3.4.6.4.e164.arpa. IN NAPTR .... > > I don't like that. You might want to store other RR types with similar > names in the same hierarchy, for example SRV records (which Microsoft > Active Directory uses heavily) or whatever. > > paf > > >> >> Martin >> >> -----Urspr=FCngliche Nachricht----- >> Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] >> Gesendet: Sonntag, 6. Juli 2003 18:32 >> An: Marian Durkovic >> Cc: enum@ietf.org; sipping@ietf.org >> Betreff: Re: [Enum] Fwd: [Sipping] I-D >> ACTION:draft-ietf-sipping-e164-03.t xt >> >> >> On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic >> wrote: >> >>> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m = wrote: >>>> Can we please keep the discussions about the wildcard in DNS=20 >>>> separate >>>> from the regular expression in NAPTR as separate as possible? >>> >>> I don't think this is fully possible. If you want to use wildcard in >>> DNS, >>> you must use non-greedy regular expression with a subpattern ( ) to >>> extract >>> and reuse the digits matched by the wildcard: >>> >>> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. >>> * IN NAPTR 100 10 "u" "E2U+sip" >>> "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . >> >> Yes, you are absolutely correct. And one can say dependencies exists=20= >> in >> the other direction as well. >> >> BUT, today I still see a large number of arguments (especially when >> looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards >> in DNS. >> >> My point is that that is not enough as an argument for removing the >> regular expression in the NAPTR for ENUM. It is needed anyway, and I >> gave an example. >> >> You say you don't want a million NAPTR records in your DNS server, = and >> I can understand that given the most common provisioning mechanisms >> which exists. >> >> The IETF do though concentrate on what goes on the wire between = hosts, >> and not so much of how things are inside the host itself. >> >> I.e. you might have some DNS software that you can configure given=20 >> some >> kind of wildcard, BUT, it will not be a wildcard from a DNS >> perspective. That is a very very big difference. The wildcard in DNS >> have many side effects -- most of them today felt being negative. >> >> paf >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 12:27:35 2003 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 MAA02204 for ; Mon, 7 Jul 2003 12:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYpX-0003Hk-WF for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 12:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67GR7Ro012609 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 12:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYpQ-0003Gp-JC; Mon, 07 Jul 2003 12:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYoj-0003Fo-VB for enum@optimus.ietf.org; Mon, 07 Jul 2003 12:26:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02181; Mon, 7 Jul 2003 12:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYog-0006Ih-00; Mon, 07 Jul 2003 12:26:14 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19ZYof-0006Ie-00; Mon, 07 Jul 2003 12:26:13 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h67GQ0o11794; Mon, 7 Jul 2003 09:26:00 -0700 (PDT) From: Bill Manning Message-Id: <200307071626.h67GQ0o11794@boreas.isi.edu> In-Reply-To: <1936.1057587606@shell.nominum.com> from Jim Reid at "Jul 7, 3 07:20:06 am" To: Jim.Reid@nominum.com (Jim Reid) Date: Mon, 7 Jul 2003 09:26:00 -0700 (PDT) Cc: md@bts.sk, paf@cisco.com, enum@ietf.org, sipping@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] wildcards ... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit draft-lewis-dns-wildcard-clarify-00.txt is worth a read, for those who have expectations on the use of wildcards. Ed would appreciate feedback. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 13:07:32 2003 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 NAA03921 for ; Mon, 7 Jul 2003 13:07:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZSE-0005iv-1q for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 13:07:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67H76QB021981 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 13:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZS9-0005h5-PD; Mon, 07 Jul 2003 13:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZRO-0005gF-N9 for enum@optimus.ietf.org; Mon, 07 Jul 2003 13:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03897; Mon, 7 Jul 2003 13:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZRM-0006q6-00; Mon, 07 Jul 2003 13:06:12 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZZRL-0006pY-00; Mon, 07 Jul 2003 13:06:12 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id B0506137F16; Mon, 7 Jul 2003 10:05:36 -0700 (PDT) To: "Martin Streller" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Marian Durkovic" , enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from "Martin Streller" of "Mon, 07 Jul 2003 17:18:40 +0200." <0E6CC1D4D38A5742930CE896A653477A2F24C7@inno-exchange.innovaphone.com> Date: Mon, 07 Jul 2003 10:05:36 -0700 Message-ID: <3840.1057597536@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Martin" == Martin Streller writes: Martin> (2) Well, it can only be a fair move to foster ongoing Martin> discussion among the DNSSEC group about this issue. However some of that discussion has to happen here IMO. The DNSSEC guys will define their protocol. But it'll be up to this WG to figure out how/if that protocol gets deployed for ENUM and what that means. Martin> (3) ff.=20 - I'd favour the record-synthesizing DNS Martin> server.=20 I guess such a gizmo at customer/corporate Martin> premises would also need to=20 be dnssec aware ? Or could Martin> I ship around this ? Pls. clarify. If your record-synthesising box also signs those records, it'll need to keep the private key on-line. This is not wise. And generating signatures on-the-fly introduces a bunch of entertaining denial of service attacks. Martin> - If you want to stay away from wildcards you should at Martin> least note that = it represents a cheap ENUM entry for Martin> low. Intricate provisioning means costs while = we're all Martin> living in a consolidating world. Indeed. But just because something is cheap doesn't necessarily mean it's the Right Thing To Do. It could mean that the real issue -- which seems to be provisioning in this case -- does not get addressed. Or else a quick+dirty solution imposes undesirable constraints on whatever is ultimately deployed. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 13:16:28 2003 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 NAA04196 for ; Mon, 7 Jul 2003 13:16:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZas-0006Rc-JU for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 13:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67HG2at024745 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 13:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZar-0006Qe-Gn; Mon, 07 Jul 2003 13:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZaJ-0006Ph-1B for enum@optimus.ietf.org; Mon, 07 Jul 2003 13:15:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04174; Mon, 7 Jul 2003 13:15:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZaH-0006yP-00; Mon, 07 Jul 2003 13:15:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19ZZaG-0006yM-00; Mon, 07 Jul 2003 13:15:24 -0400 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h67HFF618655; Mon, 7 Jul 2003 10:15:15 -0700 (PDT) From: Bill Manning Message-Id: <200307071715.h67HFF618655@boreas.isi.edu> Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: <3840.1057597536@shell.nominum.com> from Jim Reid at "Jul 7, 3 10:05:36 am" To: Jim.Reid@nominum.com (Jim Reid) Date: Mon, 7 Jul 2003 10:15:14 -0700 (PDT) Cc: MStreller@innovaphone.com, paf@cisco.com, md@bts.sk, enum@ietf.org, sipping@ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit % Martin> (2) Well, it can only be a fair move to foster ongoing % Martin> discussion among the DNSSEC group about this issue. % % However some of that discussion has to happen here IMO. The DNSSEC % guys will define their protocol. But it'll be up to this WG to figure % out how/if that protocol gets deployed for ENUM and what that means. to that end, I offer up, www.rs.net for those who wish to integrate DNSSEC into their trials. % Martin> (3) ff.=20 - I'd favour the record-synthesizing DNS % Martin> server.=20 I guess such a gizmo at customer/corporate % Martin> premises would also need to=20 be dnssec aware ? Or could % Martin> I ship around this ? Pls. clarify. % % If your record-synthesising box also signs those records, it'll need % to keep the private key on-line. This is not wise. And generating % signatures on-the-fly introduces a bunch of entertaining denial of % service attacks. online key storage does not have to have the risk profile that is presumed. Some very interesting work has been done w/ ULDR and optical links for having the private key available. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 7 18:00:43 2003 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 SAA18214 for ; Mon, 7 Jul 2003 18:00:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ze1w-0000q1-O9 for enum-archive@odin.ietf.org; Mon, 07 Jul 2003 18:00:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67M0G7V003199 for enum-archive@odin.ietf.org; Mon, 7 Jul 2003 18:00:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ze1h-0000ol-He; Mon, 07 Jul 2003 18:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ze0o-0000nv-L0 for enum@optimus.ietf.org; Mon, 07 Jul 2003 17:59:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18062 for ; Mon, 7 Jul 2003 17:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ze0m-0003Wz-00 for enum@ietf.org; Mon, 07 Jul 2003 17:59:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19Ze0l-0003Vj-00 for enum@ietf.org; Mon, 07 Jul 2003 17:59:03 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 8 Jul 2003 00:02:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233717@oefeg-s02.oefeg.loc> Thread-Topic: DNSSEC and Wildcards Thread-Index: AcNE04arMzyh0fG0T2GM6sTOeWBD0Q== From: "Stastny Richard" To: Content-Transfer-Encoding: base64 Subject: [Enum] DNSSEC and Wildcards Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RGVhciBhbGwsDQpJIGFtIG5pdCBhbiBleHBlcnQgaW4gRE5TU0VDIGFuZCBXaWxkY2FyZHMsIGJ1 dCBhcyBmYXIgYXMgSSBrbm93DQp3aWxkY2FyZHMgYXJlIHVzZWQgd2lkZXNwcmVhZCB3aXRoIE1Y IHJlY29yZHMNCklmIHRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIEROU1NFQyBhbmQgd2lsZGNhcmRz LCB0aGlzIGlzIGRlZmluaXRlbHkNCk5PVCBhbiAob25seSkgRU5VTSBwcm9ibGVtLg0KIA0KSU1I TyB0aGlzIHByb2JsZW0gc2hvdWxkIGJlIHNvbHZlZCBpbiBETlNTRUMgYW5kIG5vdCBpbiB0aGUN CkVOVU0gV0cuDQogDQpJZiB3aWxkY2FyZHMgaXMgYW4gYWxsb3dlZCBwcm9jZWR1cmUgaW4gRE5T LCBpdCBjYW4gDQpiZSB1c2VkIGluIEVOVU0uIElmIG5vdCwgaXQgc2hvdWxkIGJlIGJhbm5lZCBp biBhbGwgYXBwbGljYXRpb25zLg0KIA0KSSByZWFsbHkgZG8gbm90IHVuZGVyc3RhbmQgdGhlc2Ug YXJndW1lbnRzIGxpa2U6IHllcyB3aWxkY2FyZHMgYXJlIA0KdGhlcmUsIGJ1dCB5b3Ugc2hvdWxk IG5vdCB1c2UgdGhlbSwgb3Igb25seSBhcyBsYXN0IHJlc29ydCBhbmQgaWYNCnlvdSBjb25zaWRl ciBETlNTRUMgbGF0ZXIgeW91IHNob3VsZG50IHVzZSB0aGVtIGF0IGFsbCwgYmxhIGJsYS4NCiAN CkFzIGZhciBhcyBJIG5vdyB0aGVyZSBpcyBhbiBSRkMgYWxsb3dpbmcgd2lsZGNhcmRzIGFuZCB0 aGlzIFJGQyBpcyBub3Qgb2Jzb2xldGVkIHlldC4NCiANClJpY2hhcmQNClBTOiBQYXRyaWssIGNv dWxkIHlvdSBwbGVhc2UgZm9yd2FyZCB0aGlzIGluIHBsYWluIHRleHQgdG8gSmltIDstKQ0KIA0K _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 00:08:41 2003 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 AAA26033 for ; Tue, 8 Jul 2003 00:08:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zjm1-0007bn-ST for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 00:08:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6848DiY029234 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 00:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zjlp-0007aj-BR; Tue, 08 Jul 2003 00:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZjlG-0007QU-0H for enum@optimus.ietf.org; Tue, 08 Jul 2003 00:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26007 for ; Tue, 8 Jul 2003 00:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZjlD-0005z1-00 for enum@ietf.org; Tue, 08 Jul 2003 00:07:23 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZjlD-0005yk-00 for enum@ietf.org; Tue, 08 Jul 2003 00:07:23 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2003 06:07:04 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6844llO015004; Tue, 8 Jul 2003 06:04:48 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 06:06:51 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 06:06:50 +0200 Date: Tue, 8 Jul 2003 06:06:47 +0200 Subject: Re: [Enum] DNSSEC and Wildcards Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Stastny Richard" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <06CF906FE3998C4E944213062009F162233717@oefeg-s02.oefeg.loc> Message-Id: <98245D0A-B0F9-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 08 Jul 2003 04:06:51.0085 (UTC) FILETIME=[5BEC77D0:01C34506] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On tisdag, jul 8, 2003, at 00:02 Europe/Stockholm, Stastny Richard wrote: > I am nit an expert in DNSSEC and Wildcards, but as far as I know > wildcards are used widespread with MX records No, they are not. People using wildcards for MX in most cases (a) don't know enough about DNS and (b) use wildcards instead of fixing their provisioning systems. The only place they are used is when the MX record refer to a gateway (to X.400 or UUCP) where the other side of the gateway is managing a number of (sub-) domains, and it is impossible to point all these domains in DNS with individual MX records to the media gateway. Note the word "impossible". I really mean it. The wildcard have so many negative consequences they should not be used. I have _NEVER_ seen this for any of the examples for ENUM and E.164. Never. No one is even close. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 02:44:35 2003 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 CAA11945 for ; Tue, 8 Jul 2003 02:44:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmCt-0007hc-5b for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 02:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686i7rB029587 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 02:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmCn-0007fL-Ks; Tue, 08 Jul 2003 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmCC-0007dH-5y for enum@optimus.ietf.org; Tue, 08 Jul 2003 02:43:24 -0400 Received: from us.svf.stuba.sk (us.svf.stuba.sk [147.175.16.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11816; Tue, 8 Jul 2003 02:43:19 -0400 (EDT) Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h686fqb2093286; Tue, 8 Jul 2003 08:41:52 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h686fgt7093272; Tue, 8 Jul 2003 08:41:42 +0200 (CEST) Date: Tue, 8 Jul 2003 08:41:42 +0200 From: Marian Durkovic To: Jim Reid Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030708084142.A91895@us.svf.stuba.sk> References: <3840.1057597536@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3840.1057597536@shell.nominum.com>; from Jim.Reid@nominum.com on Mon, Jul 07, 2003 at 10:05:36AM -0700 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > Jim Reid wrote: > Indeed. But just because something is cheap doesn't necessarily mean > it's the Right Thing To Do. It could mean that the real issue -- which > seems to be provisioning in this case -- does not get addressed. Or > else a quick+dirty solution imposes undesirable constraints on > whatever is ultimately deployed. Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend a couple of minutes writing the script to generate the zone files instead of opening the topic here. The approach of having one record per every PBX extension is perhaps usable in trials, but it does not scale. Our institutions typically have 3-digit extensions, the larger ones 4-digit extensions. Having this in mind you can easily find yourself in the situation, where e.g. 300 customers generate as much as 1 million records. If there's 1 million records in top-level domain, you have 1 milion customers to cover the costs. But what will be the cost per customer, if the number of customers is 300 ? The approach with wildcards generates only 300 records per 300 customers. This is huge difference certainly worth inverstigating. > Patrik Faltstrom wrote: > The only place they are used is when the MX record refer to a gateway > (to X.400 or UUCP) where the other side of the gateway is managing a > number of (sub-) domains, and it is impossible to point all these > domains in DNS with individual MX records to the media gateway. You hit the nail. We need to do similar thing - redirect all voice traffic to a VoIP gateway connected to PBX with many many extensions. > Michael Haberler wrote: > Or do you propose to have a wildcard in the zone, and have the server > interpret it differently - i.e giving a matching non-wildcard response? This is how wildcards work _now_ with standard DNS - they are internal to the host running the DNS daemon. The end-user's resolver has no way to tell, if the response is based on wildcard or exact record, since the response is formulated as exact match in both cases. We can certaintly improve the default wildcard behaviour with more sophisticated record synthesizing, in order to get rid of common problems with classic wildcards, but I think we really need the capability for one-to-many conversion in ENUM DNS. I'd take BGP as an example. In early BGP3 stages, every C-class network has to be announced via BGP. Due to scaling issues, BGP4 has to be introduced, which enabled route aggregation. The ENUM problem is perhaps not that urgent, since ENUM zones are not dumped to every backbone router, but the basic principle is the same - the need for some form of aggregation is here now, and I think we can't close our eyes. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 03:17:35 2003 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 DAA12638 for ; Tue, 8 Jul 2003 03:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmio-0001CA-7t for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 03:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h687H6sD004581 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 03:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmil-0001BB-Oj; Tue, 08 Jul 2003 03:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmic-0001Am-T0 for enum@optimus.ietf.org; Tue, 08 Jul 2003 03:16:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12622 for ; Tue, 8 Jul 2003 03:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zmia-00079R-00 for enum@ietf.org; Tue, 08 Jul 2003 03:16:52 -0400 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 19Zmia-00079O-00 for enum@ietf.org; Tue, 08 Jul 2003 03:16:52 -0400 Received: from dialup-64.157.115.87.dial1.dallas1.level3.net ([64.157.115.87] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19ZmiZ-00046i-00; Tue, 08 Jul 2003 03:16:52 -0400 Message-ID: <3F0A8B1B.6B1AC36F@ix.netcom.com> Date: Tue, 08 Jul 2003 02:12:59 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Stastny Richard CC: enum@ietf.org Subject: Re: [Enum] DNSSEC and Wildcards References: <06CF906FE3998C4E944213062009F162233717@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12623 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Richard and all, I agree DNSSEC and wildcards should be solved in the scope of the non-existant work of late of the DNSSEC WG. However moving forward with ENUM is directly dependent on that work being completed... Stastny Richard wrote: > Dear all, > I am nit an expert in DNSSEC and Wildcards, but as far as I know > wildcards are used widespread with MX records > If there is a problem with DNSSEC and wildcards, this is definitely > NOT an (only) ENUM problem. > > IMHO this problem should be solved in DNSSEC and not in the > ENUM WG. > > If wildcards is an allowed procedure in DNS, it can > be used in ENUM. If not, it should be banned in all applications. > > I really do not understand these arguments like: yes wildcards are > there, but you should not use them, or only as last resort and if > you consider DNSSEC later you shouldnt use them at all, bla bla. > > As far as I now there is an RFC allowing wildcards and this RFC is not = obsoleted yet. > > Richard > PS: Patrik, could you please forward this in plain text to Jim ;-) > > z{=A6=99=A8=A5=8Ax%=8A=CB^=9E=E9=A2z=D7=E8=AE=08m=B6=9B?=FF0=D6'=AD~=8A= =E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F7=A7um=3D=3D Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 05:00:47 2003 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 FAA14795 for ; Tue, 8 Jul 2003 05:00:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoKi-00064y-50 for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 05:00:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6890KDl023337 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 05:00:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoKP-00063X-Gi; Tue, 08 Jul 2003 05:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoJs-00062p-Bi for enum@optimus.ietf.org; Tue, 08 Jul 2003 04:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14750; Tue, 8 Jul 2003 04:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoJo-0007iI-00; Tue, 08 Jul 2003 04:59:24 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19ZoJn-0007hv-00; Tue, 08 Jul 2003 04:59:23 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h688wlL4010450; Tue, 8 Jul 2003 10:58:48 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307080858.h688wlL4010450@bartok.sidn.nl> To: Marian Durkovic cc: Jim Reid , enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Tue, 08 Jul 2003 08:41:42 +0200. <20030708084142.A91895@us.svf.stuba.sk> Date: Tue, 08 Jul 2003 10:58:46 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend a couple of minutes writing the script to generate the zone files instead of opening the topic here. The approach of having one record per every PBX extension is perhaps usable in trials, but it does not scale. Our institutions typically have 3-digit extensions, the larger ones 4-digit extensions. Having this in mind you can easily find yourself in the situation, where e.g. 300 customers generate as much as 1 million records. If there's 1 million records in top-level domain, you have 1 milion customers to cover the costs. But what will be the cost per customer, if the number of customers is 300 ? Most instances of this idea with customers with n-bit extensions PBX I'm familar with, are actually maintaining such a PBX themselves. If theu want top do ENUM, the obvious solution is to delegate to that customer. The approach with wildcards generates only 300 records per 300 customers. This is huge difference certainly worth inverstigating. > Patrik Faltstrom wrote: > The only place they are used is when the MX record refer to a gateway > (to X.400 or UUCP) where the other side of the gateway is managing a > number of (sub-) domains, and it is impossible to point all these > domains in DNS with individual MX records to the media gateway. You hit the nail. We need to do similar thing - redirect all voice traffic to a VoIP gateway connected to PBX with many many extensions. No, that is different. You can delegate to a nameserver which maintains that part of the name space for that particular PBX. There is no need to populate the toplevel with all the nitty gritty details of that PBX. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 05:09:28 2003 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 FAA15264 for ; Tue, 8 Jul 2003 05:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoT7-0006s2-Ty for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 05:09:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68991ml026403 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 05:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoT7-0006rQ-GG; Tue, 08 Jul 2003 05:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoSh-0006n6-Tk for enum@optimus.ietf.org; Tue, 08 Jul 2003 05:08:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15233; Tue, 8 Jul 2003 05:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoSe-00003k-00; Tue, 08 Jul 2003 05:08:32 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZoSe-00002q-00; Tue, 08 Jul 2003 05:08:32 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 76130137F0D; Tue, 8 Jul 2003 02:08:02 -0700 (PDT) To: Marian Durkovic Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Marian Durkovic of "Tue, 08 Jul 2003 08:41:42 +0200." <20030708084142.A91895@us.svf.stuba.sk> Date: Tue, 08 Jul 2003 02:08:02 -0700 Message-ID: <20561.1057655282@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> The approach of having one record per every PBX extension Marian> is perhaps usable in trials, but it does not scale. Our Marian> institutions typically have 3-digit extensions, the larger Marian> ones 4-digit extensions. Having this in mind you can Marian> easily find yourself in the situation, where e.g. 300 Marian> customers generate as much as 1 million records. If Marian> there's 1 million records in top-level domain, you have 1 Marian> milion customers to cover the costs. But what will be the Marian> cost per customer, if the number of customers is 300 ? I don't understand the point you're trying to make here. You seem to be saying something "won't scale" for 300 names but somehow scales just fine for 1 million names. I'm confused. And you've still to explain why provisioning NAPTRs for each number -- something you said was trivial -- couldn't be done and why a wildcard RR was the only possible solution to the problem you're trying to solve. Despite what you said earlier, this still looks to me that the wildcard has been suggested as a kludge to work around a provisioning problem. And a straightforward one at that. Marian> The approach with wildcards generates only 300 records per Marian> 300 customers. This is huge difference certainly worth Marian> inverstigating. It has even bigger implications which you don't seem to appreciate. You've not given any convincing explanation why a wildcard RR is the only solution and why alternatives are not viable. Please provide that explanation. >> Patrik Faltstrom wrote: The only place they are used is when >> the MX record refer to a gateway (to X.400 or UUCP) where the >> other side of the gateway is managing a number of (sub-) >> domains, and it is impossible to point all these domains in DNS >> with individual MX records to the media gateway. Marian> You hit the nail. We need to do similar thing - redirect Marian> all voice traffic to a VoIP gateway connected to PBX with Marian> many many extensions. Well this is a perfect example of why DNS wildcards provide the wrong answer to the wrong question. You're assuming that the only use of ENUM for some range of numbers would be to contact a VoIP gateway. This cannot be guaranteed. What happens when the owners of (some of) those numbers want additional NAPTRs for other services? What if they *don't* want to use this default VoIP gateway? Or can't use it. What happens with numbers that are not in service? Should applications which look these up be pointed at the VoIP gateway regardless? That's what you'd get with a wildcard. Maybe it would be better to get an NXDOMAIN response from the DNS. Which of course you can't get if there's a wildcard RR. The same goes for numbers that are invalid because they don't have the correct number of digits. What if some of the active numbers must not be used for VoIP because they're bound to things like a fax machine or a modem? What if you need to introduce additional VoIP gateways for some or all of the numbers? BTW, what you're proposing is NOT similar to the scenario Patrik outlined at all. You're talking about a known, well-defined, if large, name space: a range of telephone numbers. It is possible to enumerate all the domain names that exist there. In fact, it's trivial. In the scenario Patrik explains the wildcard MX record covers a name space that is not known and cannot be enumerated because it is somewhat unstructured and dynamic. >> Michael Haberler wrote: Or do you propose to have a wildcard in >> the zone, and have the server interpret it differently - i.e >> giving a matching non-wildcard response? Marian> This is how wildcards work _now_ with standard DNS - they Marian> are internal to the host running the DNS daemon. The Marian> end-user's resolver has no way to tell, if the response is Marian> based on wildcard or exact record, since the response is Marian> formulated as exact match in both cases. We can certaintly Marian> improve the default wildcard behaviour with more Marian> sophisticated record synthesizing, in order to get rid of Marian> common problems with classic wildcards, Sorry, you can't change the semantics of DNS wildcarding without a wholesale protocol rewrite. And somehow keeping backwards compatibility with the installed base. Please show how you intend to do this. For bonus points, get the DNS WGs to adopt your proposal. :-) Marian> but I think we really need the capability for one-to-many Marian> conversion in ENUM DNS. I've not seen any justification for this so far though I accept it might be useful. Perhaps you could provide some examples? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 08:24:41 2003 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 IAA18989 for ; Tue, 8 Jul 2003 08:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrW0-0006qO-BM for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 08:24:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68COCpP026302 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 08:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrVp-0006pa-KM; Tue, 08 Jul 2003 08:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZrUz-0006p4-Ax for enum@optimus.ietf.org; Tue, 08 Jul 2003 08:23:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18949; Tue, 8 Jul 2003 08:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZrUy-00015u-00; Tue, 08 Jul 2003 08:23:08 -0400 Received: from inno-exchange.innovaphone.com ([145.253.157.4] helo=innovaphone.com) by ietf-mx with esmtp (Exim 4.12) id 19ZrUx-00015q-00; Tue, 08 Jul 2003 08:23:07 -0400 content-class: urn:content-classes:message Subject: AW: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jul 2003 14:22:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0E6CC1D4D38A5742930CE896A653477A1813CD@inno-exchange.innovaphone.com> Thread-Topic: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcNFMJmzwqA/9NvoRfSolWJugXzByAAGqNpQ From: "Martin Streller" To: "Jim Reid" , "Marian Durkovic" Cc: , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, please see below, Btw, with customers I also include institutions, like Marian. Martin >>>>> "Marian" =3D=3D Marian Durkovic writes: Marian> The approach of having one record per every PBX = extension Marian> is perhaps usable in trials, but it does not scale. Our Marian> institutions typically have 3-digit extensions, the = larger Marian> ones 4-digit extensions. Having this in mind you can Marian> easily find yourself in the situation, where e.g. 300 Marian> customers generate as much as 1 million records. If Marian> there's 1 million records in top-level domain, you have = 1 Marian> milion customers to cover the costs. But what will be = the Marian> cost per customer, if the number of customers is 300 ? I don't understand the point you're trying to make here. You seem to be saying something "won't scale" for 300 names but somehow scales just fine for 1 million names. I'm confused. And you've still to explain why provisioning NAPTRs for each number -- something you = said was trivial -- couldn't be done and why a wildcard RR was the only possible solution to the problem you're trying to solve. Despite = what you said earlier, this still looks to me that the wildcard has been suggested as a kludge to work around a provisioning problem. And a straightforward one at that. Marian> The approach with wildcards generates only 300 records = per Marian> 300 customers. This is huge difference certainly worth Marian> inverstigating. It has even bigger implications which you don't seem to appreciate. You've not given any convincing explanation why a wildcard RR is the only solution and why alternatives are not viable. Please provide = that explanation.=20 >> Patrik Faltstrom wrote: The only place they are used is when >> the MX record refer to a gateway (to X.400 or UUCP) where the >> other side of the gateway is managing a number of (sub-) >> domains, and it is impossible to point all these domains in = DNS >> with individual MX records to the media gateway. Marian> You hit the nail. We need to do similar thing - redirect Marian> all voice traffic to a VoIP gateway connected to PBX = with Marian> many many extensions. Well this is a perfect example of why DNS wildcards provide the = wrong answer to the wrong question. You're assuming that the only use of ENUM for some range of numbers would be to contact a VoIP gateway.=20 [Martin] Within our customer range, eventually interested in ENUM, the VoIP = gateway centric view is the only that makes sense. ENUM is for them interesting = as a kind of Least-Cost-Routing. Firstly try to call by means of = ENUM/H.323, secondly call via the costly PSTN. All this is handled within the VoIP gateway = and applies=20 for outbound calls.=20 Of course do they want to be reachable inbound via ENUM/H.323, as well.=20 Without devoting man-power, without bearing additional costs.=20 Such customers typically do already have a VoIP gateway and a dial-up = connection to the Internet. They typically do not have a DNS server. So, what's = more elegant than submitting a single NAPTR RR that is hosted elsewhere and covers = the PSTN root number of=20 this company ? This cannot be guaranteed. What happens when the owners of (some of) = those numbers want additional NAPTRs for other services?=20 [Martin] Our customer community did not wait for ENUM in its entirety. They're = interested in telephone-related aspects. So, no additional NAPTRs wanted here. =20 What if they *don't* want to use this default VoIP gateway?=20 [Martin] They want, because they typically have a single one. Or can't use it. What happens with numbers that are not in service?=20 [Martin] A call attempt is being made and the call cannot be established. Very = much like in the PSTN world. =20 Should applications which look these up be pointed at the VoIP gateway regardless?=20 [Martin] Yes. That's what you'd get with a wildcard.=20 [Martin] And exactly this is welcome. Maybe it would be better to get an NXDOMAIN response from the DNS. Which of course you can't get if there's a wildcard RR. The same goes for numbers that are invalid because they don't have the correct number of digits.=20 [Martin] As I stated earlier, there is no problem with numbers that are = incomplete=20 or "overdialled". If e.g. a call with an incomplete number arrives at a = VoIP gateway, the gateway accepts the call but does not send back an ALERT. Through = the, from now on, established call signalling session the call originator gets the = opportunity to submit further digits without consulting the ENUM track anymore. This is called = overlapped-dialling. What if some of the active numbers must not be used for VoIP because they're bound to things = like a fax machine or a modem?=20 [Martin] Fax over IP (FoIP) is already happening today. Everything that applies = for VoIP can be taken into account for FoIP. Again no problem here. Modem over IP may = be not that widespread, however the same point of view here. What if you need to introduce additional VoIP gateways for some or all of the numbers? [Martin] Hmhh, not sure what you mean, do you refer to load balancing of inbound = calls ? If yes, this would mean a totally different thread. BTW, what you're proposing is NOT similar to the scenario Patrik outlined at all. You're talking about a known, well-defined, if = large, name space: a range of telephone numbers. It is possible to = enumerate all the domain names that exist there. In fact, it's trivial. In the scenario Patrik explains the wildcard MX record covers a name space that is not known and cannot be enumerated because it is somewhat unstructured and dynamic. [Martin] If I could go to my NAPTR RR hoster's website and could enter: - my root number as +49 703173009=20 - my desired number range like: from 10 to 99=20 - my h323 URI then I'd be happy. I wouldn't insist on wildcards. In other words I want to to be able to do it one time for my whole number range within 10 minutes and then forget it. >> Michael Haberler wrote: Or do you propose to have a wildcard = in >> the zone, and have the server interpret it differently - i.e >> giving a matching non-wildcard response? Marian> This is how wildcards work _now_ with standard DNS - = they Marian> are internal to the host running the DNS daemon. The Marian> end-user's resolver has no way to tell, if the response = is Marian> based on wildcard or exact record, since the response is Marian> formulated as exact match in both cases. We can = certaintly Marian> improve the default wildcard behaviour with more Marian> sophisticated record synthesizing, in order to get rid = of Marian> common problems with classic wildcards, Sorry, you can't change the semantics of DNS wildcarding without a wholesale protocol rewrite. And somehow keeping backwards compatibility with the installed base. Please show how you intend to do this. For bonus points, get the DNS WGs to adopt your proposal. = :-) Marian> but I think we really need the capability for = one-to-many Marian> conversion in ENUM DNS. I've not seen any justification for this so far though I accept it might be useful. Perhaps you could provide some examples? [Martin] You been getting the examples from Marian and me. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 09:21:35 2003 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 JAA20835 for ; Tue, 8 Jul 2003 09:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsP5-0001ZG-Vq for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 09:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68DL7JK006020 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 09:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsOy-0001XP-O4; Tue, 08 Jul 2003 09:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsOM-0001WY-Td for enum@optimus.ietf.org; Tue, 08 Jul 2003 09:20:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20760; Tue, 8 Jul 2003 09:20:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZsOL-0001Vz-00; Tue, 08 Jul 2003 09:20:21 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZsOK-0001Vg-00; Tue, 08 Jul 2003 09:20:20 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h68DK5b2010694; Tue, 8 Jul 2003 15:20:05 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h68DK0hY010693; Tue, 8 Jul 2003 15:20:00 +0200 (CEST) Date: Tue, 8 Jul 2003 15:20:00 +0200 From: Marian Durkovic To: Jim Reid Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030708152000.B5311@us.svf.stuba.sk> References: <20561.1057655282@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20561.1057655282@shell.nominum.com>; from Jim.Reid@nominum.com on Tue, Jul 08, 2003 at 02:08:02AM -0700 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Tue, Jul 08, 2003 at 10:58:46AM +0200, Jaap Akkerhuis wrote: > Most instances of this idea with customers with n-bit extensions > PBX I'm familar with, are actually maintaining such a PBX themselves. > If theu want top do ENUM, the obvious solution is to delegate to > that customer. [snip] You can delegate to a nameserver which > maintains that part of the name space for that particular PBX. > There is no need to populate the toplevel with all the nitty gritty > details of that PBX. Sure, those records would not appear in the toplevel, but at the ISP level, since the customers either outsource the DNS to them or at least request a backup DNS to be operated by the ISP. On Tue, Jul 08, 2003 at 02:08:02AM -0700, Jim Reid wrote: > I don't understand the point you're trying to make here. You seem to > be saying something "won't scale" for 300 names but somehow scales > just fine for 1 million names. I'm confused. And you've still to > explain why provisioning NAPTRs for each number -- something you said > was trivial -- couldn't be done and why a wildcard RR was the only > possible solution to the problem you're trying to solve. No, I'm saying that 300 PBX customers might create as much 1 million records. Operating DNS servers with millions of records is not a trivial task at least not for commonly available DNS software and just this is IMHO a good reason to look for alternatives which make more decent use of resources. > Well this is a perfect example of why DNS wildcards provide the wrong > answer to the wrong question. You're assuming that the only use of > ENUM for some range of numbers would be to contact a VoIP gateway. This > cannot be guaranteed. What happens when the owners of (some of) those > numbers want additional NAPTRs for other services? I'm not saying everyone _should_ use wildcards for every possible configuration. But plese don't do the opposite - i.e. don't tell me that we _must not_ use them. > What if they *don't* > want to use this default VoIP gateway? Or can't use it. You might still point the wildcard towards e.g. SIP proxy server, which can handle this more effectively (changes are visible immediately). > with numbers that are not in service? Should applications which look > these up be pointed at the VoIP gateway regardless? That's what you'd > get with a wildcard. Maybe it would be better to get an NXDOMAIN > response from the DNS. Which of course you can't get if there's a > wildcard RR. This can only introduce another point of failure. This would mean, that PBX configuration and DNS configuration must be always in sync which is hard to achieve. Better get the "No subscriber" from the PBX like with PSTN. > The same goes for numbers that are invalid because they > don't have the correct number of digits. What if some of the active > numbers must not be used for VoIP because they're bound to things like > a fax machine or a modem? What if you need to introduce additional > VoIP gateways for some or all of the numbers? Again, you can point the wildcard towards e.g. SIP proxy and introduce much more services. > Sorry, you can't change the semantics of DNS wildcarding without a > wholesale protocol rewrite. And somehow keeping backwards > compatibility with the installed base. Please show how you intend to > do this. I don't. I was mentioning record synthesizing indepened of classic wildcards and their problems. > Marian> but I think we really need the capability for one-to-many > Marian> conversion in ENUM DNS. > > I've not seen any justification for this so far though I accept it > might be useful. Perhaps you could provide some examples? DID (Direct Inward Dial) is a standard telco service that the customers are used to. Emulating it by enumerating all possible digit combinations could be only considered as a workaround and is in many cases pure waste of resources. If the wildcards are no good, other solution has to be found. M. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 09:49:35 2003 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 JAA21492 for ; Tue, 8 Jul 2003 09:49:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsq9-00032o-Tv for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 09:49:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Dn5RO011666 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 09:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsq5-00031J-Ly; Tue, 08 Jul 2003 09:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zspl-00030I-2l for enum@optimus.ietf.org; Tue, 08 Jul 2003 09:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21471; Tue, 8 Jul 2003 09:48:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zspi-0001ff-00; Tue, 08 Jul 2003 09:48:38 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19Zsph-0001fW-00; Tue, 08 Jul 2003 09:48:37 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h68DlwL4011435; Tue, 8 Jul 2003 15:47:59 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307081347.h68DlwL4011435@bartok.sidn.nl> To: Marian Durkovic cc: Jim Reid , enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Tue, 08 Jul 2003 15:20:00 +0200. <20030708152000.B5311@us.svf.stuba.sk> Date: Tue, 08 Jul 2003 15:47:58 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , No, I'm saying that 300 PBX customers might create as much 1 million records. Operating DNS servers with millions of records is not a trivial task at least not for commonly available DNS software and just this is IMHO a good reason to look for alternatives which make more decent use of resources. Did you ever try? I'm running a zone with about 3.7 Million records om a standard PC with standard DNS software. No sweat. In case you want to know, that is the signed .nl zone (DNSSEC). The normal zone has about 1.9 records and runs also on commonly known DNS implementations (Bind 8 & 9, nsd). The DNS server is not a problem. As said the provisioning is. A proper registriation system which keeps track of all the (differenvt) records is the problem. If the (sets of) records are the same, you can easely generate these in some automatic fashion. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 09:55:30 2003 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 JAA21659 for ; Tue, 8 Jul 2003 09:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsvv-0003St-1L for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 09:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Dt3er013315 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 09:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsvt-0003S8-OJ; Tue, 08 Jul 2003 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsva-0003RV-15 for enum@optimus.ietf.org; Tue, 08 Jul 2003 09:54:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21635; Tue, 8 Jul 2003 09:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZsvX-0001iU-00; Tue, 08 Jul 2003 09:54:40 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19ZsvX-0001iQ-00; Tue, 08 Jul 2003 09:54:39 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h68DriC18222; Tue, 8 Jul 2003 13:53:44 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 09:54:48 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C80@stntexch2.va.neustar.com> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Tue, 8 Jul 2003 09:54:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Without speaking to the DNS wildcarding issue as a whole, I suppose that given the public outcry we should pass over this whole greedy regexp issue in silence in sipping-e164. Though ultimately I believe that the use of non-greedy regexps in ENUM encourages NAPTR records for partial numbers (which in turn encourage wildcarding, etc), I certainly don't feel strongly enough about this that I think we need to mandate against it, and I guess I could just drop the current RECOMMENDation. Some other notes below. Jon Peterson NeuStar, Inc. > > > > I'm not suggesting that clients refuse to process records with more complex > > regexp antecedents if they happen to receive them - this is in a section of > > advice for authors of NAPTR records, not a specification of resolver > > behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis > > compliance in any way. > > Why should they ignore it? They still have to _implement_ it. The people or systems that create the NAPTR records which are provisioned in the DNS do not have to 'implement' resolvers. [snip] > > > The restriction in the sipping-e164 document basically > > reinforces this (at a RECOMMENDED level, not as a mandatory statement), but > > given that this seems to be a controversial matter, perhaps it would be best > > if we passed over this in silence in the SIPPING document as well. > > [snip] > > This has _nothing_ to do with partial numbers. > > Let's then change the example to: > > 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > > foo.bar.example.com. IN NAPTR .... > "!^+4(.*)$!sip:9876\1@anotherexample.net!" > Well, all right, given this clever example, I agree that authors of records don't necessarily have to use partial E.164 numbers in order to use a non-greedy regexp antecedent in NAPTRs. But, authors of records don't really have any incentive to make records structured like this, in which you have to enumerate every number in the numbering plan in a CNAME record. Rather, they want to have a single NAPTR record for a partial number (as in the other examples aired on the list have suggested). > paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 10:07:31 2003 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 KAA22656 for ; Tue, 8 Jul 2003 10:07:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt7Y-0004EX-GF for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 10:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68E74D6016238 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 10:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt7V-0004Cm-Fs; Tue, 08 Jul 2003 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zt7Q-0004C3-D3 for enum@optimus.ietf.org; Tue, 08 Jul 2003 10:06:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563 for ; Tue, 8 Jul 2003 10:06:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zt7O-0001rI-00 for enum@ietf.org; Tue, 08 Jul 2003 10:06:54 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Zt7N-0001qr-00 for enum@ietf.org; Tue, 08 Jul 2003 10:06:53 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <33ATA9B5>; Tue, 8 Jul 2003 15:06:21 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 33A4C0KA; Tue, 8 Jul 2003 15:06:18 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Cc: MStreller@innovaphone.com, md@bts.sk, jaap@sidn.nl, Jim.Reid@nominum.com Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 8 Jul 2003 15:06:18 +0100 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] PLEASE STOP CROSS-POSTING! Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Dear Marian, Jaap, Martin, Jim, Please will you stop cross posting to SIPPING as well as ENUM on what has become a pure ENUM/DNS thread. It's interesting, but I only need one copy :). Many thanks, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 10:31:34 2003 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 KAA24504 for ; Tue, 8 Jul 2003 10:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtUq-0005TZ-83 for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 10:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68EV8QT021049 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 10:31:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtUj-0005Sw-Bd; Tue, 08 Jul 2003 10:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZtUB-0005S7-MQ for enum@optimus.ietf.org; Tue, 08 Jul 2003 10:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24466; Tue, 8 Jul 2003 10:30:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtU9-00028u-00; Tue, 08 Jul 2003 10:30:25 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZtU8-00028e-00; Tue, 08 Jul 2003 10:30:24 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2003 16:30:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h68ERgHX011377; Tue, 8 Jul 2003 16:27:47 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 16:29:47 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 16:29:47 +0200 Date: Tue, 8 Jul 2003 16:29:44 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C80@stntexch2.va.neustar.com> Message-Id: <9EC5E078-B150-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 08 Jul 2003 14:29:47.0364 (UTC) FILETIME=[61EC0A40:01C3455D] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On tisdag, jul 8, 2003, at 15:54 Europe/Stockholm, Peterson, Jon wrote: > Without speaking to the DNS wildcarding issue as a whole, I suppose > that > given the public outcry we should pass over this whole greedy regexp > issue > in silence in sipping-e164. Though ultimately I believe that the use of > non-greedy regexps in ENUM encourages NAPTR records for partial numbers > (which in turn encourage wildcarding, etc), I certainly don't feel > strongly > enough about this that I think we need to mandate against it, and I > guess I > could just drop the current RECOMMENDation. Personally, I would appreciate you dropping it. People implementing things should not "just implement what they need" (which often is a partial solution). I (and many with me) remember when MIME was started to be adopted where text/plain messages could have a charset parameter. Many many implementations didn't implement the Content-Transfer-Encoding mechanism, and only took for granted ISO 8859-1 was in use. When they later launched services and had customers in for example Japan, they didn't understand what was wrong... You have probably seen similar things with SIP... Better write implementation guidelines which are written so people can not cheat. If they do anyway, they must definitely know what they are doing (and why they are cheating). And, I agree with you that the ones doing the provisioning are not the same writing the code. BUT, writing the code and get it to work is a one-time-thing, although difficult. With experience from Cisco implementing the whole-nine-yards I can tell you the problem is not the regexp engine. The problem is to get the configuration tool working correctly so the _selection_ of NAPTR records is correct, and possible to understand for the one which configure whatever the programmer is creating. paf > Some other notes below. > > Jon Peterson > NeuStar, Inc. > >>> >>> I'm not suggesting that clients refuse to process records with more > complex >>> regexp antecedents if they happen to receive them - this is in a >>> section > of >>> advice for authors of NAPTR records, not a specification of resolver >>> behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis >>> compliance in any way. >> >> Why should they ignore it? They still have to _implement_ it. > > The people or systems that create the NAPTR records which are > provisioned in > the DNS do not have to 'implement' resolvers. > > [snip] >> >>> The restriction in the sipping-e164 document basically >>> reinforces this (at a RECOMMENDED level, not as a mandatory >>> statement), > but >>> given that this seems to be a controversial matter, perhaps it would >>> be > best >>> if we passed over this in silence in the SIPPING document as well. >>> > [snip] >> >> This has _nothing_ to do with partial numbers. >> >> Let's then change the example to: >> >> 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. >> 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. >> 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. >> >> foo.bar.example.com. IN NAPTR .... >> "!^+4(.*)$!sip:9876\1@anotherexample.net!" >> > > Well, all right, given this clever example, I agree that authors of > records > don't necessarily have to use partial E.164 numbers in order to use a > non-greedy regexp antecedent in NAPTRs. But, authors of records don't > really > have any incentive to make records structured like this, in which you > have > to enumerate every number in the numbering plan in a CNAME record. > Rather, > they want to have a single NAPTR record for a partial number (as in the > other examples aired on the list have suggested). > >> paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 11:20:47 2003 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 LAA26313 for ; Tue, 8 Jul 2003 11:20:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuGQ-00081C-SG for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 11:20:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68FKIrA030808 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 11:20:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuG9-00080A-Vw; Tue, 08 Jul 2003 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuFq-0007z3-2v for enum@optimus.ietf.org; Tue, 08 Jul 2003 11:19:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26243 for ; Tue, 8 Jul 2003 11:19:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZuFo-0002Um-00 for enum@ietf.org; Tue, 08 Jul 2003 11:19:40 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZuFo-0002Tn-00 for enum@ietf.org; Tue, 08 Jul 2003 11:19:40 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id CBEDC137F0D; Tue, 8 Jul 2003 08:19:03 -0700 (PDT) To: "Martin Streller" Cc: "Marian Durkovic" , enum@ietf.org In-Reply-To: Message from "Martin Streller" of "Tue, 08 Jul 2003 14:22:58 +0200." <0E6CC1D4D38A5742930CE896A653477A1813CD@inno-exchange.innovaphone.com> Date: Tue, 08 Jul 2003 08:19:03 -0700 Message-ID: <26591.1057677543@shell.nominum.com> From: Jim Reid Subject: [Enum] Solving provisioning problems with DNS wildcards Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Martin" == Martin Streller writes: Martin> If I could go to my NAPTR RR hoster's website and could Martin> enter: - my root number as +49 703173009=20 - my desired Martin> number range like: from 10 to 99=20 - my h323 URI then I'd Martin> be happy. I wouldn't insist on wildcards. In other words Martin> I want to to be able to do it one time for my whole number Martin> range within 10 minutes and then forget it. In other words, this really is a provisioning problem after all. It shouldn't need to involve DNS wildcards. Jim> I've not seen any justification for this so far though Jim> I accept it might be useful. Perhaps you could provide Jim > some examples? Martin> You been getting the examples from Marian and me. Er, no. With respect, the example you've given -- it seems to be the same one from both you and Marian -- describe a provisioning issue that can be kludged around with DNS wildcarding. This is unlikely to be a justification for deploying wildcards that most DNS people would understand and endorse. If you recall Patrik's earlier remarks, these can be paraphrased as "show why there's no other option to using wildcards". This remains to be shown IMO. NB: I've taken sipping@ietf.org off this thread to keep Lawrence happy. And I've changed the Subject: header to something more meaningful too. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 8 14:40:50 2003 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 OAA03673 for ; Tue, 8 Jul 2003 14:40:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxNz-0004NX-Ch for enum-archive@odin.ietf.org; Tue, 08 Jul 2003 14:40:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68IeJEC016784 for enum-archive@odin.ietf.org; Tue, 8 Jul 2003 14:40:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxNg-0004GQ-M6; Tue, 08 Jul 2003 14:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxMs-0004FG-8i for enum@optimus.ietf.org; Tue, 08 Jul 2003 14:39:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03594 for ; Tue, 8 Jul 2003 14:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxMp-0004Ty-00 for enum@ietf.org; Tue, 08 Jul 2003 14:39:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19ZxMo-0004TI-00 for enum@ietf.org; Tue, 08 Jul 2003 14:39:07 -0400 content-class: urn:content-classes:message Subject: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 8 Jul 2003 20:43:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F16223371B@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcNFMA+e9PNswmriTfqNsoasffeikAAT3+Pu From: "Stastny Richard" To: "Jaap Akkerhuis" , "Marian Durkovic" Cc: "Jim Reid" , Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SmFhcCB3cm90ZToNCg0KCQ0KDQoJPk5vLCB0aGF0IGlzIGRpZmZlcmVudC4gWW91IGNhbiBkZWxl Z2F0ZSB0byBhIG5hbWVzZXJ2ZXIgd2hpY2gNCgk+bWFpbnRhaW5zIHRoYXQgcGFydCBvZiB0aGUg bmFtZSBzcGFjZSBmb3IgdGhhdCBwYXJ0aWN1bGFyIFBCWC4NCgk+VGhlcmUgaXMgbm8gbmVlZCB0 byBwb3B1bGF0ZSB0aGUgdG9wbGV2ZWwgd2l0aCBhbGwgdGhlIG5pdHR5IGdyaXR0eQ0KCT5kZXRh aWxzIG9mIHRoYXQgUEJYLg0KCQ0KCSAgT2ssIGFuZCB3aGF0IGFyZSB5b3UgZG9pbmcgdGhlcmU/ IE9mIGNvdXJzZSB0aGVyZSBpcyBubyBuZWVkIHRvIGRvIHRoaXMgYXQgVGllciAxDQoJKEkgYXNz dW1lIHRoYXRzIHdoYXQgeW91IGNhbGwgdG9wbGV2ZWwpLCBidXQgeW91IHRoZW4gaGF2ZSB0byBk byBpdCBhdCBUaWVyIDIgKG9yIDMpLg0KCVJpY2hhcmQgICAgDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 9 06:58:57 2003 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 GAA27309 for ; Wed, 9 Jul 2003 06:58:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCed-0002S3-N8 for enum-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69AwV17009408 for enum-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeB-0002DC-0D; Wed, 09 Jul 2003 06:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aC2p-0006tP-Vx for enum@optimus.ietf.org; Wed, 09 Jul 2003 06:19:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26337 for ; Wed, 9 Jul 2003 06:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aC2m-0005fG-00 for enum@ietf.org; Wed, 09 Jul 2003 06:19:24 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19aC2l-0005f6-00 for enum@ietf.org; Wed, 09 Jul 2003 06:19:23 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h69AIqL4018000 for ; Wed, 9 Jul 2003 12:18:53 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307091018.h69AIqL4018000@bartok.sidn.nl> To: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Tue, 08 Jul 2003 20:43:05 +0200. <06CF906FE3998C4E944213062009F16223371B@oefeg-s02.oefeg.loc> Date: Wed, 09 Jul 2003 12:18:52 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >No, that is different. You can delegate to a nameserver which >maintains that part of the name space for that particular PBX. >There is no need to populate the toplevel with all the nitty gritty >details of that PBX. Ok, and what are you doing there? Of course there is no need to do this at Tier 1 (I assume thats what you call toplevel), but you then have to do it at Tier 2 (or 3). You have to do that in whatever level the name space is delegated to. I know of a campus place that has a phone number block like +12 34 567XXXX. On the campus are seperate entities, each running a part of the name/nummer space for themselves (each have their own PBX). The XXXX namespace is devided by a central body in smaller portions and each maintain a PBX for their parts of the name space. So one can imagen that the whole block (7.6.5.4.3.2.1.e164.arpa) is delegated to the central body and that one can populate the rest of the block or even delegate again to the separate entities such as 1.7.6.5.4.3.2.1.e164.arpa to group A, 2.7.6.5.4.3.2.1.e164.arpa to group B etc. (BTW I avoid terms as Tiers # here. Sometimes in some contexts they have specific meanings. What I want to point out here is that the DNS system is hierachical. Delegations may appear at every level (label) and that might be useful to do so in certain occasions). jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 9 11:14:26 2003 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 LAA05033 for ; Wed, 9 Jul 2003 11:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdp-0001dy-Mi for enum-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDvfq006289 for enum-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd0-0000y7-Uv; Wed, 09 Jul 2003 11:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aDwd-0002Vm-89 for enum@optimus.ietf.org; Wed, 09 Jul 2003 08:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28681 for ; Wed, 9 Jul 2003 08:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aDwc-0006JH-00 for enum@ietf.org; Wed, 09 Jul 2003 08:21:10 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19aDwa-0006J2-00 for enum@ietf.org; Wed, 09 Jul 2003 08:21:09 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h69CKub2042605; Wed, 9 Jul 2003 14:20:56 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h69CKpwl042604; Wed, 9 Jul 2003 14:20:51 +0200 (CEST) Date: Wed, 9 Jul 2003 14:20:51 +0200 From: Marian Durkovic To: Jaap Akkerhuis Cc: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030709142051.A39654@us.svf.stuba.sk> References: <06CF906FE3998C4E944213062009F16223371B@oefeg-s02.oefeg.loc> <200307091018.h69AIqL4018000@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307091018.h69AIqL4018000@bartok.sidn.nl>; from jaap@sidn.nl on Wed, Jul 09, 2003 at 12:18:52PM +0200 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Jul 09, 2003 at 12:18:52PM +0200, Jaap Akkerhuis wrote: > > >No, that is different. You can delegate to a nameserver which > >maintains that part of the name space for that particular PBX. > >There is no need to populate the toplevel with all the nitty gritty > >details of that PBX. > > Ok, and what are you doing there? Of course there is no > need to do this at Tier 1 (I assume thats what you call > toplevel), but you then have to do it at Tier 2 (or 3). > > You have to do that in whatever level the name space is delegated > to. I know of a campus place that has a phone number block like +12 > 34 567XXXX. On the campus are seperate entities, each running a > part of the name/nummer space for themselves (each have their own > PBX). The XXXX namespace is devided by a central body in smaller > portions and each maintain a PBX for their parts of the name space. > So one can imagen that the whole block (7.6.5.4.3.2.1.e164.arpa) > is delegated to the central body and that one can populate the rest > of the block or even delegate again to the separate entities such > as 1.7.6.5.4.3.2.1.e164.arpa to group A, 2.7.6.5.4.3.2.1.e164.arpa > to group B etc. Yes, but this works only if the institutions are well experienced, and each of the smaller entities operates 2 DNS servers. With companies totally unrelated to IT it's obvious that they outsource things like DNS to some service providers, which might get overwhelmed with the growing number of records if all possible numbers need to exist in DNS. Yes, they can run DNS with millions of records but it's certainly slower, takes time to start up and is more sensitive to DOS attacks compared to the one with hudreds of one-to-many records - which are sufficient in many cases. M. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 9 11:48:32 2003 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 LAA06824 for ; Wed, 9 Jul 2003 11:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHAq-0006ps-U1 for enum-archive@odin.ietf.org; Wed, 09 Jul 2003 11:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Fm4tg026261 for enum-archive@odin.ietf.org; Wed, 9 Jul 2003 11:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHAm-0006p5-Oe; Wed, 09 Jul 2003 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHA3-0006fJ-1g for enum@optimus.ietf.org; Wed, 09 Jul 2003 11:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06765 for ; Wed, 9 Jul 2003 11:47:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHA1-0007j6-00 for enum@ietf.org; Wed, 09 Jul 2003 11:47:13 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19aHA0-0007is-00 for enum@ietf.org; Wed, 09 Jul 2003 11:47:12 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id A361D137F04; Wed, 9 Jul 2003 08:46:30 -0700 (PDT) To: Marian Durkovic Cc: Jaap Akkerhuis , enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Marian Durkovic of "Wed, 09 Jul 2003 14:20:51 +0200." <20030709142051.A39654@us.svf.stuba.sk> Date: Wed, 09 Jul 2003 08:46:30 -0700 Message-ID: <55642.1057765590@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> Yes, but this works only if the institutions are well Marian> experienced, and each of the smaller entities operates 2 Marian> DNS servers. With companies totally unrelated to IT it's Marian> obvious that they outsource things like DNS to some Marian> service providers, which might get overwhelmed with the Marian> growing number of records if all possible numbers need to Marian> exist in DNS. I fail to see how this is remotely relevant to the discussion about wildcard RRs. If a service provider can't do their job properly, find another one! Marian> Yes, they can run DNS with millions of Marian> records but it's certainly slower, takes time to start up Marian> and is more sensitive to DOS attacks compared to the one Marian> with hudreds of one-to-many records - which are sufficient Marian> in many cases. Eh? If a DNS server is too slow at loading zones, pick another one! I know of at least 5 DNS implementations that offer near-instant zone loading (or equivalent). I don't see how DoS attacks are relevant either: this is orthogonal to the issue of zone load times. BTW, BIND9 is multi-threaded so it can load zones and answer queries at the same time, unlike BIND8. Not that anyone should be using BIND8 for ENUM related stuff anyway. And have you considered the potential for DoS attacks that get introduced by having wildcards? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 9 12:00:58 2003 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 LAA05034 for ; Wed, 9 Jul 2003 11:14:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdp-0001dp-MB for enum-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDvgN006290 for enum-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd6-00014W-F3; Wed, 09 Jul 2003 11:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aETr-00065Y-5M for enum@optimus.ietf.org; Wed, 09 Jul 2003 08:55:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29192 for ; Wed, 9 Jul 2003 08:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aETp-0006PL-00 for enum@ietf.org; Wed, 09 Jul 2003 08:55:29 -0400 Received: from bartok.sidn.nl ([193.176.144.164]) by ietf-mx with esmtp (Exim 4.12) id 19aETo-0006P1-00 for enum@ietf.org; Wed, 09 Jul 2003 08:55:28 -0400 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h69CsuL4019021 for ; Wed, 9 Jul 2003 14:54:57 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200307091254.h69CsuL4019021@bartok.sidn.nl> To: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-reply-to: Your message of Wed, 09 Jul 2003 14:20:51 +0200. <20030709142051.A39654@us.svf.stuba.sk> Date: Wed, 09 Jul 2003 14:54:56 +0200 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Note I said: Delegations may appear at every level (label) and that might be useful to do so in certain occasions. Yes, but this works only if the institutions are well experienced, and each of the smaller entities operates 2 DNS servers. With companies totally unrelated to IT it's obvious that they outsource things like DNS to some service providers, which might get overwhelmed with the growing number of records if all possible numbers need to exist in DNS. So you you want concentrate on solutions for people without a clue who outsource to other clueless people? Yes, they can run DNS with millions of records but it's certainly slower, takes time to start up and is more sensitive to DOS attacks compared to the one with hundreds of one-to-many records There are commonly available nameservers out there that do start quickly with millions of records, but apart from that, what has the amount of records to do with DOS attacks? one one-to-many records - which are sufficient in many cases. Jim, Patrick and I were making the point that it is not a DNS problem, there are quite some ways to solve the provisioning problems. That wild cards are not the sole answer since they come with new problems so people should look to other solutions first. It is like the proverb: ``if your only tool is a hammer, the world looks like a nail''. It seems to me that the advice to look into the toolbox for something other then a hammer doesn't seem to be accepted by you. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 9 23:03:48 2003 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 XAA03264 for ; Wed, 9 Jul 2003 23:03:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aRiL-0005bI-TG for enum-archive@odin.ietf.org; Wed, 09 Jul 2003 23:03:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A33LkT021521 for enum-archive@odin.ietf.org; Wed, 9 Jul 2003 23:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aRi1-0005ad-IC; Wed, 09 Jul 2003 23:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aRhm-0005aO-7h for enum@optimus.ietf.org; Wed, 09 Jul 2003 23:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03227 for ; Wed, 9 Jul 2003 23:02:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aRhi-0006P9-00 for enum@ietf.org; Wed, 09 Jul 2003 23:02:42 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19aRhh-0006Ou-00 for enum@ietf.org; Wed, 09 Jul 2003 23:02:41 -0400 Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6A35oF21992; Wed, 9 Jul 2003 20:05:50 -0700 Message-Id: <5.2.0.9.2.20030709225702.02746378@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 23:02:58 -0400 To: enum@ietf.org From: Richard Shockey Cc: jmorris@cdt.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Privacy and Security Draft for discussion in Vienna Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , The authors sincerely apologize for the lateness of this draft however we welcome comments in advance of meeting in Vienna. http://www.shockey.us/enum/draft-ietf-enum-privacy-security-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 10 04:30:45 2003 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 EAA22362 for ; Thu, 10 Jul 2003 04:30:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWol-0002K6-07 for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 04:30:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8UIk7008931 for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 04:30:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWoT-0002JO-NN; Thu, 10 Jul 2003 04:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWni-0002Hs-JH for enum@optimus.ietf.org; Thu, 10 Jul 2003 04:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22329 for ; Thu, 10 Jul 2003 04:29:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWnf-0000XA-00 for enum@ietf.org; Thu, 10 Jul 2003 04:29:11 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19aWnd-0000Wt-00 for enum@ietf.org; Thu, 10 Jul 2003 04:29:10 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h6A8Svb2061144; Thu, 10 Jul 2003 10:28:57 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h6A8SqR7061143; Thu, 10 Jul 2003 10:28:52 +0200 (CEST) Date: Thu, 10 Jul 2003 10:28:52 +0200 From: Marian Durkovic To: Jaap Akkerhuis Cc: enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030710102852.C58776@us.svf.stuba.sk> References: <20030709142051.A39654@us.svf.stuba.sk> <200307091254.h69CsuL4019021@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307091254.h69CsuL4019021@bartok.sidn.nl>; from jaap@sidn.nl on Wed, Jul 09, 2003 at 02:54:56PM +0200 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , On Wed, Jul 09, 2003 at 02:54:56PM +0200, Jaap Akkerhuis wrote: > So you you want concentrate on solutions for people without a clue > who outsource to other clueless people? Well, ENUM is not a standard important to experts-only like BGP, but its intended audience is in principle anyone using the telephone. Experts in e.g. medicine and law have no need to understand DNS so outsourcing is a natural solution. > It seems to me that the advice to look into the toolbox for something > other then a hammer doesn't seem to be accepted by you. No, the problem here is we're looking at the same thing from a different perspective. I've never said DNS wildcards will solve all the world's problems. What I'm saying is that there's a serious scalability issue rising from the fact, that today, most of DNS zones contain just a few records - for web server(s), mail server(s) etc. With the aproach of enumerating all possible combinations, the ENUM zone for a PBX customer will be 3 orders of magnitute (!) bigger than the zone for his domain. If these are to be hosted by service providers, their DNS has to be prepared for 3 orders of magnitude more records. That's why I'm suggesting to start looking for other solutions. But you and Jim seem to be denying that any problem actually exists and consider this to be only a provisioning issue. Well, if all service providers anywhere in the world are running .COM sized DNS server, there's certainly no problem. But that's not true and, by the way, tomorrow some other group might propose another important application based on DNS... So my point is - it's better to think twice how we use the resources and if wildcards are no good let's try to find some other solution for one-to-many translation. With kind regards, M. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 10 05:10:34 2003 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 FAA23351 for ; Thu, 10 Jul 2003 05:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXRJ-0005TL-BP for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 05:10:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A9A93k021031 for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 05:10:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXRB-0005Sp-H2; Thu, 10 Jul 2003 05:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXQm-0005ST-Oo for enum@optimus.ietf.org; Thu, 10 Jul 2003 05:09:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23348 for ; Thu, 10 Jul 2003 05:09:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXQj-0000my-00 for enum@ietf.org; Thu, 10 Jul 2003 05:09:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19aXQi-0000mv-00 for enum@ietf.org; Thu, 10 Jul 2003 05:09:33 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2003 11:09:11 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6A96uQJ022094; Thu, 10 Jul 2003 11:06:57 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 11:09:02 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 11:09:01 +0200 Date: Thu, 10 Jul 2003 11:09:00 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jaap Akkerhuis , enum@ietf.org To: Marian Durkovic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030710102852.C58776@us.svf.stuba.sk> Message-Id: <2515006A-B2B6-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 10 Jul 2003 09:09:01.0789 (UTC) FILETIME=[E77DD8D0:01C346C2] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On torsdag, jul 10, 2003, at 10:28 Europe/Stockholm, Marian Durkovic wrote: > If these are to be hosted by service providers, their DNS has to be > prepared for 3 orders of magnitude more records. If, as you claim, the number of records in a zone is too large for a DNS server you have, this can be solved in a very simple way. The way ENUM is defined, delegations can be made at any digit in the E.164 number. This means you can split your block of E.164 numbers onto any number of DNS servers. Each one of them only holding some k*10 records (where k is small). They because of this don't have to change DNS software, but instead buy more computers and make sure their provisioning system can handle the distributed scenario. That way you also distribute the load regarding potential increase in the number of lookups being made. > So my point is - it's better > to think twice how we use the resources and if wildcards are no good > let's > try to find some other solution for one-to-many translation. What we are trying to say is that you should try to solve the real problem you have, and if no other solution exists, you can use wildcards in DNS. You seem to say (that is what I read at least, even though that is not your intention): "Wildcards in DNS are ok as a default answer until proven otherwise" which Jim, Jaap, myself and others object to. This together with us not understanding what real problem you have part from a provisioning issue. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 10 06:08:36 2003 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 GAA24672 for ; Thu, 10 Jul 2003 06:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYLT-0000QP-3v for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 06:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AA8B74001627 for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 06:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYLI-0000Ph-Uw; Thu, 10 Jul 2003 06:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYKw-0000LY-BO for enum@optimus.ietf.org; Thu, 10 Jul 2003 06:07:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24634 for ; Thu, 10 Jul 2003 06:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aYKs-0001A3-00 for enum@ietf.org; Thu, 10 Jul 2003 06:07:34 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19aYKr-00019e-00 for enum@ietf.org; Thu, 10 Jul 2003 06:07:33 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 8A012137F32; Thu, 10 Jul 2003 03:07:03 -0700 (PDT) To: Marian Durkovic Cc: Jaap Akkerhuis , enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Marian Durkovic of "Thu, 10 Jul 2003 10:28:52 +0200." <20030710102852.C58776@us.svf.stuba.sk> Date: Thu, 10 Jul 2003 03:07:03 -0700 Message-ID: <31590.1057831623@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> Well, ENUM is not a standard important to experts-only Marian> like BGP, but its intended audience is in principle anyone Marian> using the telephone. Experts in e.g. medicine and law have Marian> no need to understand DNS so outsourcing is a natural Marian> solution. Well it's one solution. There are others. Like better tools. The idea that people manage their DNS data and name servers with text editors has to die if DNS is going to pervade households and small offices. The idea of someone like my mother running vi on a zone file simply isn't going to work. >> It seems to me that the advice to look into the toolbox for >> something other then a hammer doesn't seem to be accepted by >> you. Marian> No, the problem here is we're looking at the same thing Marian> from a different perspective. I've never said DNS Marian> wildcards will solve all the world's problems. What I'm Marian> saying is that there's a serious scalability issue rising Marian> from the fact, that today, most of DNS zones contain just Marian> a few records - for web server(s), mail server(s) etc. With all respect, you have not been saying that until now. Marian> That's why I'm suggesting to start looking for other Marian> solutions. But you and Jim seem to be denying that any Marian> problem actually exists and consider this to be only a Marian> provisioning issue. I can't speak for Patrik, though I think he agrees with me. Yes, there is a problem. But it's a provisioning problem: how to manage the data that will be fed to the name servers. As far as the task of serving that data goes, there is no practical problem in the DNS. That's a matter of scaling and we know how inherently scalable the DNS is. The proof is all around us. Marian> anywhere in the world are running .COM sized DNS server, Marian> there's certainly no problem. But that's not true and, by Marian> the way, tomorrow some other group might propose another Marian> important application based on DNS... They're already out there. DNSSEC is one. RFID tags are another. That technology will have a *much bigger* impact on the DNS than ENUM. Marian> So my point is - it's better to think twice how we use the Marian> resources and if wildcards are no good let's try to find Marian> some other solution for one-to-many translation. I'm glad we're in agreement at last. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 10 06:16:25 2003 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 GAA25170 for ; Thu, 10 Jul 2003 06:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYT2-0001TU-Eb for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 06:16:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AAG0QH005652 for enum-archive@odin.ietf.org; Thu, 10 Jul 2003 06:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYT1-0001Sm-Uj; Thu, 10 Jul 2003 06:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aYSi-0001SW-F6 for enum@optimus.ietf.org; Thu, 10 Jul 2003 06:15:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25090 for ; Thu, 10 Jul 2003 06:15:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aYSe-0001JA-00 for enum@ietf.org; Thu, 10 Jul 2003 06:15:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19aYSd-0001J7-00 for enum@ietf.org; Thu, 10 Jul 2003 06:15:36 -0400 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19aYSe-000GSj-OX; Thu, 10 Jul 2003 10:15:36 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19aYSd-0003nc-0o; Thu, 10 Jul 2003 12:15:35 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jul 2003 12:15:34 +0200 To: Marian Durkovic Cc: Jaap Akkerhuis , enum@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt References: <20030709142051.A39654@us.svf.stuba.sk> <200307091254.h69CsuL4019021@bartok.sidn.nl> <20030710102852.C58776@us.svf.stuba.sk> Message-Id: Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Well, ENUM is not a standard important to experts-only like BGP, but its > intended audience is in principle anyone using the telephone. bgp is not a standard important to experts-only, but its intended audience is in principle anyone using the internet. in case the above is too subtle, do not confuse the importance of an *underlying* technology with the end users' need to understand it. q: do telephone users understand how a 5ess works? a: actually, no one does randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 11 06:21:12 2003 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 GAA23975 for ; Fri, 11 Jul 2003 06:21:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av1C-0003ej-43 for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 06:20:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BAKke5014044 for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 06:20:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av0T-0003ah-Tz; Fri, 11 Jul 2003 06:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av0E-0003WW-Ez for enum@optimus.ietf.org; Fri, 11 Jul 2003 06:19:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23897 for ; Fri, 11 Jul 2003 06:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19av0A-0004Pe-00 for enum@ietf.org; Fri, 11 Jul 2003 06:19:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19av09-0004PJ-00 for enum@ietf.org; Fri, 11 Jul 2003 06:19:41 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jul 2003 12:23:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F16223372E@oefeg-s02.oefeg.loc> Thread-Topic: regexp does not match Thread-Index: AcNHlcYwtVnZvsJBRqObBrwNxnRw7g== From: "Stastny Richard" To: Content-Transfer-Encoding: quoted-printable Subject: [Enum] regexp does not match Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, but especially to MM We talked a lot in the last days in ENUM about _greedy_ regexp that do always match. But what about _real_ regexp that does NOT match the AUS. I tried to find an explicit statement about this either in rfc2916bis or rfc3403, but did not find it (maybe it is there, but ...).=20 To my understanding, the NAPTR then has to be ignored. Is this correct? regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 11 07:41:38 2003 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 HAA25675 for ; Fri, 11 Jul 2003 07:41:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awGz-000242-Qn for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 07:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BBf9HK007923 for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 07:41:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awGp-00023H-Ot; Fri, 11 Jul 2003 07:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awGJ-00022p-7m for enum@optimus.ietf.org; Fri, 11 Jul 2003 07:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25649 for ; Fri, 11 Jul 2003 07:40:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19awGI-0004uO-00 for enum@ietf.org; Fri, 11 Jul 2003 07:40:26 -0400 Received: from [209.10.143.221] (helo=neonym.net) by ietf-mx with esmtp (Exim 4.12) id 19awGH-0004uL-00 for enum@ietf.org; Fri, 11 Jul 2003 07:40:26 -0400 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 10 Jul 2003 17:25:23 -0400 Subject: Re: [Enum] regexp does not match From: Michael Mealling To: Stastny Richard Cc: enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F16223372E@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F16223372E@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1057923534.18998.207.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jul 2003 07:38:54 -0400 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-07-11 at 06:23, Stastny Richard wrote: > Hi all, but especially to MM > > We talked a lot in the last days in ENUM about _greedy_ regexp that do > always match. > But what about _real_ regexp that does NOT match the AUS. > > I tried to find an explicit statement about this either in rfc2916bis or > rfc3403, but did not find > it (maybe it is there, but ...). > > To my understanding, the NAPTR then has to be ignored. Is this correct? Yep. Its there in the algorithm. If the regexp doesn't match you go to the next record, if it never matches then you'll simply pass over it... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 11 10:20:39 2003 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 KAA01090 for ; Fri, 11 Jul 2003 10:20:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayku-0005st-Aj for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 10:20:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BEKCa5022613 for enum-archive@odin.ietf.org; Fri, 11 Jul 2003 10:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayki-0005dU-Pq; Fri, 11 Jul 2003 10:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayju-0005P1-2b for enum@optimus.ietf.org; Fri, 11 Jul 2003 10:19:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01060 for ; Fri, 11 Jul 2003 10:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayjr-0005wf-00 for enum@ietf.org; Fri, 11 Jul 2003 10:19:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19ayjq-0005wL-00 for enum@ietf.org; Fri, 11 Jul 2003 10:19:07 -0400 content-class: urn:content-classes:message Subject: RE: [Enum] Privacy and Security Draft for discussion in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jul 2003 16:23:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233736@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Privacy and Security Draft for discussion in Vienna Thread-Index: AcNGkItdFL6ugV7mSlONADZ02wWqUABINkdA From: "Stastny Richard" To: "Richard Shockey" , Cc: Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, first I want to congratulate the authors for this document, it is describing very consistensly and also neutrally the issues with ENUM regarding security and privacy. The question now is how to proceed with the issues raised. I would propose to split the issues in different parts, as already started in the document The reason for this is that we have security and privacy issues. So the first split is in security and privacy issues. 1. Security Issues: 1a Security issues that are of direct concern to IETF and also can be solved by IETF (e.g. all DNS related issues, primarily DNSSEC) - 5.2 1b Security issues related to provisioning - 5.1 Here we have IETF related parts as mentioned, eg EPP 1c Security issues related to the administration and consistency of the E.164 numbering plan, including validation Since this is dependant also on national regulations, this is out of scope of IETF, but maybe some experiences and best practices may be exchanged 2. Privacy Issues Privacy isues are a serious problem for all kinds of communication and the approach to this problem choosen in the document is in my opinion a good one and should be continued. First, different people have different requirements on privacy So the privacy concerns or problems should be recognized and hints should be given how to deal with this concerns. The protocols (not only ENUM, but also SIP, email, etc.) should be able to deal with this problems.=20 This means that the issues raised in the document should be analysed in more details and result finally in additional requirements for the communications protocols and in a document giving guidelines to users how to use these protocol enhancements properly. Example: The most serious problem raised with ENUM is the spam problem. In my opinion the spam problem cannot be solved by not implementing translation or directory services, it can only be solved by implementing on one side proper laws against spam and on the other side proper tools to enforce this laws. This means in case of VoIP, email and ENUM that a proper and trustable way to identify calling parties is necessary. We should not forget that the purpose of communication is to be able to communicate and to achieve this, directory services are necessary (I know, ENUM is NOT a directory service, but it enables e.g. existing directory services for E.164 numbers to be used for other applications also). And we should also not forget that directory services are a basic part of the universal service (at least in some countries). And a way to be ex-directory, but also in ENUM has already be shown. And BTW, having no directory services at all will not solve the spam problem. regards Richard Stastny > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Thursday, July 10, 2003 5:03 AM > To: enum@ietf.org > Cc: jmorris@cdt.org > Subject: [Enum] Privacy and Security Draft for discussion in Vienna >=20 >=20 >=20 > The authors sincerely apologize for the lateness of this=20 > draft however we=20 > welcome comments in advance of meeting in Vienna. >=20 http://www.shockey.us/enum/draft-ietf-enum-privacy-security-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 14 07:20:09 2003 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 HAA09652 for ; Mon, 14 Jul 2003 07:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1Mp-0007DI-DV for enum-archive@odin.ietf.org; Mon, 14 Jul 2003 07:19:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EBJdjs027716 for enum-archive@odin.ietf.org; Mon, 14 Jul 2003 07:19:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1MD-00078F-2y; Mon, 14 Jul 2003 07:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0gY-0003eQ-NO for enum@optimus.ietf.org; Mon, 14 Jul 2003 06:36:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06261; Mon, 14 Jul 2003 06:35:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0gU-00043F-00; Mon, 14 Jul 2003 06:35:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=arachne) by ietf-mx with esmtp (Exim 4.12) id 19c0gT-00042l-00; Mon, 14 Jul 2003 06:35:53 -0400 Received: by arachne (Postfix, from userid 1000) id 2BA991A368; Mon, 14 Jul 2003 13:36:03 +0200 (CEST) Date: Mon, 14 Jul 2003 13:36:03 +0200 From: Otmar Lendl To: Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= Cc: "Peterson, Jon" , "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030714113603.GA10219@eunet-ag.at> References: <0449D80A0E9B614A83FA9031B07E8D3B257C80@stntexch2.va.neustar.com> <9EC5E078-B150-11D7-BE0E-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <9EC5E078-B150-11D7-BE0E-000A959CF516@cisco.com> User-Agent: Mutt/1.3.28i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAB06262 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On 2003/07/08 16:07, Patrik F=E4ltstr=F6m wrote: >=20 > With experience from Cisco implementing the whole-nine-yards I can tell= =20 > you the problem is not the regexp engine.=20 FYI, I implemeted the full regex substitution algorithm for the=20 Asterisk PBX last week. Calls to Marian utilizing his wildcard NAPTRs worked fine. Based on the Posix regex functions included in the Linux libc, that took about 3 hours and 50 lines of C code. (and some glances at how ser is doing that stuff.) Bringing the code for full precedence/multiple NAPTRs/multiple servicespecs in one NAPTR/tel:-recursion (if needed) - handling up to RFC compliance gives me more headaches. From my point of view, there are the real pitfalls for ENUM resolver implementations. /ol _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 14 10:08:38 2003 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 KAA22228 for ; Mon, 14 Jul 2003 10:08:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3zw-0007AZ-44 for enum-archive@odin.ietf.org; Mon, 14 Jul 2003 10:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EE8C9W027544 for enum-archive@odin.ietf.org; Mon, 14 Jul 2003 10:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3zl-00078i-O3; Mon, 14 Jul 2003 10:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3zf-00077t-GY for enum@optimus.ietf.org; Mon, 14 Jul 2003 10:07:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22092 for ; Mon, 14 Jul 2003 10:07:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3zd-0000AP-00 for enum@ietf.org; Mon, 14 Jul 2003 10:07:53 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19c3zb-00009o-00 for enum@ietf.org; Mon, 14 Jul 2003 10:07:52 -0400 Date: Mon, 14 Jul 2003 16:11:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <06CF906FE3998C4E944213062009F16223373B@oefeg-s02.oefeg.loc> Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] VoIP and ENUM Demo thread-index: AcNFIuerA8M1zR2yTtCdwiJrxFFmzwE7dDi/ From: "Stastny Richard" To: Content-Transfer-Encoding: base64 Subject: [Enum] Reminder: VoIP and ENUM Demo Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCmFzIGFscmVhZHkgc3RhdGVkLCBhIFZvSVAgYW5kIEVOVU0gZGVtbyB3aWxs IHRha2UgcGxhY2UNCg0Kb24gVGh1cnNkYXksIEp1bHkgMTd0aCBhdCAxNTMwIGluIHRoZSB0ZXJt aW5hbCByb29tIGF0IHRoZSBJRVRGLg0KDQpNZWV0aW5nIHBvaW50IGlzIGF0IHRoZSByZWdpc3Ry YXRpb24gZGVzayBhdCAxNTE1Lg0KDQpUaGUgZGVtbyB3aWxsIHNob3cgdGhlIGludGVyd29ya2lu ZyBvZiBkaWZmZXJlbnQgVm9JUCBhcHBsaWNhdGlvbnMgd2l0aCBFTlVNLA0KDQphbmQgYWxzbyB0 aGUgQXVzdHJpYW4gRU5VTSB0cmlhbC4gUGFydGl6aXBhbnRzIG9mIHRoZSBBdXN0cmlhbiBFTlVN IHRyaWFsIHdpbGwNCg0KYmUgYXZhaWxhYmxlIGZvciBhbnN3ZXJpbmcgcXVlc3Rpb25zLg0KDQpi ZXN0IHJlZ2FyZHMNClJpY2hhcmQNCg0KUmljaGFyZCBTVEFTVE5ZDQpPZUZFRy9UZWxla29tIEF1 c3RyaWENCkJveCAxNDcsIEEtMTEwMyBWaWVubmEsIEF1c3RyaWENCnRlbDorNDMgNjY0IDQyMCA0 MTAwDQpmYXg6KzQzIDEgNzk3IDgwIDEzDQptYWlsdG86cmljaGFyZC5zdGFzdG55QG9lZmVnLmF0 DQoNCg0KDQoNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 15 04:09:59 2003 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 EAA02542 for ; Tue, 15 Jul 2003 04:09:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKsP-0005aA-BY for enum-archive@odin.ietf.org; Tue, 15 Jul 2003 04:09:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F89XG5021412 for enum-archive@odin.ietf.org; Tue, 15 Jul 2003 04:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKrt-0005SG-6V; Tue, 15 Jul 2003 04:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKqx-0005LE-6t for enum@optimus.ietf.org; Tue, 15 Jul 2003 04:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02341 for ; Tue, 15 Jul 2003 04:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKqu-0005s9-00 for enum@ietf.org; Tue, 15 Jul 2003 04:08:00 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19cKqr-0005qa-00 for enum@ietf.org; Tue, 15 Jul 2003 04:07:58 -0400 Received: from rshockeybox.shockey.us (rshockeybox.ietf57.telekom.at [81.160.178.147] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6F8B7F10027 for ; Tue, 15 Jul 2003 01:11:07 -0700 Message-Id: <5.2.0.9.2.20030714103054.04d05e90@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 15 Jul 2003 04:08:25 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] given the substantial interest in the ENUM trial Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I've taken the liberty of making them avaiable early to those of you who are interested. http://www.shockey.us/enum/ietf57-enum-koreatrial.ppt http://www.shockey.us/enum/ietf57-enum-swedentrial.pdf http://www.shockey.us/enum/ietf57-enum-uktrial.ppt http://www.shockey.us/enum/ietf57-enum-austriatrial.ppt I'll keep these on line for a couple of weeks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 04:23:24 2003 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 EAA22567 for ; Fri, 18 Jul 2003 04:23:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQW0-0001Sj-Hu for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 04:22:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I8MuI6005603 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 04:22:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQV8-0001Nv-0G; Fri, 18 Jul 2003 04:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQUe-0001NY-CW for enum@optimus.ietf.org; Fri, 18 Jul 2003 04:21:32 -0400 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22443 for ; Fri, 18 Jul 2003 04:21:29 -0400 (EDT) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6I8EreN017479 for ; Fri, 18 Jul 2003 10:15:12 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 10:17:03 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 10:17:03 +0200 Date: Fri, 18 Jul 2003 10:17:00 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 18 Jul 2003 08:17:03.0358 (UTC) FILETIME=[F81109E0:01C34D04] Content-Transfer-Encoding: 7bit Subject: [Enum] CRISP Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There has been some side-discussions about what I as chair saw happening with regards to the CRISP/ENUM draft which was presented at the meeting. My conclusion, after asking Andy and Michael, is that: - The CRISP wg is working on the CRISP architecture, and the ENUM wg is happy "someone else is solving this problem" - The document editors want the ENUM wg to evaluate the data model in the CRISP/ENUM document - There was not consensus whether the document should be added to the charter of the ENUM wg First of all, if people don't agree with my view, send a message to the list. Secondly, I see absolutely no problem with using the ENUM mailing list for discussions about this ENUM/CRISP draft. Richard and myself will check with our AD's what they think about adding this and other documents to the charter. I.e. the overall question for us chairs is what this wg is to do next. Conclusion: This document must be reviewed. The ENUM experts are on the ENUM mailing list. Whether the document is on the charter or not should not make any difference for the existence of the discussion. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 05:02:35 2003 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 FAA23807 for ; Fri, 18 Jul 2003 05:02:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7v-0003OQ-DD for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I927Dl013042 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:02:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7q-0003KK-DM; Fri, 18 Jul 2003 05:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dR7Y-0003J0-Gb for enum@optimus.ietf.org; Fri, 18 Jul 2003 05:01:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23759 for ; Fri, 18 Jul 2003 05:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dR7V-0006ht-00 for enum@ietf.org; Fri, 18 Jul 2003 05:01:41 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19dR7K-0006hD-00 for enum@ietf.org; Fri, 18 Jul 2003 05:01:30 -0400 Received: (qmail 24583 invoked from network); 18 Jul 2003 09:05:42 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.176.129) by sentosa.post1.com with SMTP; 18 Jul 2003 09:05:42 -0000 Message-ID: <3F17B725.4020104@pobox.org.sg> Date: Fri, 18 Jul 2003 17:00:21 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: enum@ietf.org Subject: Re: [Enum] CRISP References: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> In-Reply-To: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA23760 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Personal opinion: I am trying to stay away from CRISP and if I need to deal with it, only=20 with a ten foot pole. The discussion of whois-like information is=20 red-herring, with a presumption business model, that may or may not=20 makes sense for ENUM. In fact, it is not clear to me that it is even applicable to ENUM=20 deployment. (Do you really need to provide "registrant" information of a=20 ENUM phone number in public?) -James Seng Patrik F=E4ltstr=F6m wrote: > There has been some side-discussions about what I as chair saw happenin= g=20 > with regards to the CRISP/ENUM draft which was presented at the meeting. >=20 > My conclusion, after asking Andy and Michael, is that: >=20 > - The CRISP wg is working on the CRISP architecture, and > the ENUM wg is happy "someone else is solving this problem" > - The document editors want the ENUM wg to evaluate the > data model in the CRISP/ENUM document > - There was not consensus whether the document should be > added to the charter of the ENUM wg >=20 > First of all, if people don't agree with my view, send a message to the= =20 > list. >=20 > Secondly, I see absolutely no problem with using the ENUM mailing list=20 > for discussions about this ENUM/CRISP draft. >=20 > Richard and myself will check with our AD's what they think about addin= g=20 > this and other documents to the charter. I.e. the overall question for=20 > us chairs is what this wg is to do next. >=20 > Conclusion: This document must be reviewed. The ENUM experts are on the= =20 > ENUM mailing list. Whether the document is on the charter or not should= =20 > not make any difference for the existence of the discussion. >=20 > paf >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 05:27:41 2003 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 FAA24425 for ; Fri, 18 Jul 2003 05:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRWE-0004oB-TT for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9REU6018456 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRW1-0004i1-Bl; Fri, 18 Jul 2003 05:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRV4-0004gJ-Ux for enum@optimus.ietf.org; Fri, 18 Jul 2003 05:26:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24369 for ; Fri, 18 Jul 2003 05:25:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRV1-0006yH-00 for enum@ietf.org; Fri, 18 Jul 2003 05:25:59 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19dRUq-0006wi-00 for enum@ietf.org; Fri, 18 Jul 2003 05:25:48 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6I9LTIl002357; Fri, 18 Jul 2003 11:21:30 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 11:23:01 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 11:23:00 +0200 Date: Fri, 18 Jul 2003 11:22:58 +0200 Subject: Re: [Enum] CRISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org To: James Seng From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3F17B725.4020104@pobox.org.sg> Message-Id: <6BCB981B-B901-11D7-84A0-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 18 Jul 2003 09:23:01.0019 (UTC) FILETIME=[2F042EB0:01C34D0E] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jul 18, 2003, at 11:00 Europe/Stockholm, James Seng wrote: > In fact, it is not clear to me that it is even applicable to ENUM > deployment. (Do you really need to provide "registrant" information of > a ENUM phone number in public?) No, but possibly information about the technical (etc) contact of the ENUM Service provider, i.e. the one running the DNS server for the NAPTR RR's for a specific E.164 (and NS records above these records in the DNS hierarchy). paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 05:36:30 2003 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 FAA24931 for ; Fri, 18 Jul 2003 05:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRel-0005bM-NX for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:36:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9a3h8021526 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 05:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRek-0005ap-PD; Fri, 18 Jul 2003 05:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dReh-0005aa-PS for enum@optimus.ietf.org; Fri, 18 Jul 2003 05:35:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24902 for ; Fri, 18 Jul 2003 05:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRee-00075L-00 for enum@ietf.org; Fri, 18 Jul 2003 05:35:56 -0400 Received: from [216.93.164.123] (helo=zak.ecotroph.net) by ietf-mx with esmtp (Exim 4.12) id 19dReT-00074t-00 for enum@ietf.org; Fri, 18 Jul 2003 05:35:45 -0400 Received: from ecotroph.net ([::ffff:81.160.15.63]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Fri, 18 Jul 2003 05:34:12 -0400 Message-ID: <3F17BF0F.7070501@ecotroph.net> Date: Fri, 18 Jul 2003 05:34:07 -0400 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable To: James Seng CC: "=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=" , enum@ietf.org Subject: Re: [Enum] CRISP References: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> <3F17B725.4020104@pobox.org.sg> In-Reply-To: <3F17B725.4020104@pobox.org.sg> X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.39.3 Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm not sure about the comment regarding a business model. Certainly none has surfaced in any of the conversations I have heard nor any of the documents I have seen. We should take note of the historical context we have today, and understand that there are things such as multiple roles (e.g. NOC vs. abuse) and multiple types of contact (e.g. email vs. civil address), and= that with these come the responsibilities that should have been undertaken on port 43 but never materialized. The reason we have CRISP today is that the Internet community historically did not give port 43 the necessary long view and suddenly found itself looking back upon a series of wrong turns. Simply ignoring= the problem or doing the bare minimum is how it all started. Let us not repeat the mistakes of the past so clearly visible today. With regard to Patrik's note: I agree. The intent of the draft is not to entangle the ENUM group into the finer details of CRISP. It is simply asking for review by the ENUM working group of a data model to be= used by those operators who do have a need for this. And there is no intent to mandate its use nor to define a single, authoritative model. -andy James Seng wrote: > Personal opinion: > > I am trying to stay away from CRISP and if I need to deal with it, onl= y > with a ten foot pole. The discussion of whois-like information is > red-herring, with a presumption business model, that may or may not > makes sense for ENUM. > > In fact, it is not clear to me that it is even applicable to ENUM > deployment. (Do you really need to provide "registrant" information of= a > ENUM phone number in public?) > > -James Seng > > Patrik F=E4ltstr=F6m wrote: > >> There has been some side-discussions about what I as chair saw >> happening with regards to the CRISP/ENUM draft which was presented at= >> the meeting. >> >> My conclusion, after asking Andy and Michael, is that: >> >> - The CRISP wg is working on the CRISP architecture, and >> the ENUM wg is happy "someone else is solving this problem" >> - The document editors want the ENUM wg to evaluate the >> data model in the CRISP/ENUM document >> - There was not consensus whether the document should be >> added to the charter of the ENUM wg >> >> First of all, if people don't agree with my view, send a message to >> the list. >> >> Secondly, I see absolutely no problem with using the ENUM mailing lis= t >> for discussions about this ENUM/CRISP draft. >> >> Richard and myself will check with our AD's what they think about >> adding this and other documents to the charter. I.e. the overall >> question for us chairs is what this wg is to do next. >> >> Conclusion: This document must be reviewed. The ENUM experts are on >> the ENUM mailing list. Whether the document is on the charter or not >> should not make any difference for the existence of the discussion. >> >> paf >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> >> > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enu > m _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 06:30:37 2003 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 GAA26147 for ; Fri, 18 Jul 2003 06:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSV9-0008D7-2c for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:30:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAUB67031557 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSUz-0008Ae-B6; Fri, 18 Jul 2003 06:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSUp-0008A6-1K for enum@optimus.ietf.org; Fri, 18 Jul 2003 06:29:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26099 for ; Fri, 18 Jul 2003 06:29:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSUl-0007YW-00 for enum@ietf.org; Fri, 18 Jul 2003 06:29:47 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19dSUa-0007Xa-00 for enum@ietf.org; Fri, 18 Jul 2003 06:29:36 -0400 Received: (qmail 26193 invoked from network); 18 Jul 2003 10:33:39 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.176.129) by sentosa.post1.com with SMTP; 18 Jul 2003 10:33:39 -0000 Message-ID: <3F17CBBF.10101@pobox.org.sg> Date: Fri, 18 Jul 2003 18:28:15 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Andrew Newton CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Subject: Re: [Enum] CRISP References: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> <3F17B725.4020104@pobox.org.sg> <3F17BF0F.7070501@ecotroph.net> In-Reply-To: <3F17BF0F.7070501@ecotroph.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA26100 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The assumption that people actually wants to put their private=20 information available in some database to access does not makes sense to=20 me. CRISP serves a small group of "users" and does not benefit the rest of=20 Internet users at large. (how would it helps my Mom to use ENUM from=20 this ENUM-CRISP work?) This is not to say all information is useless. I certainly cant disagree=20 with Patrik to put ENUM service provider information available because=20 it helps in operation. The other reasons I am against the work is because we have very little=20 operational experiences (on the whole) to actually know what info we=20 want to put in public and whats not. Are you sure we have the capability to review the "data model"? The use=20 case of ENUM is not even well-defined yet! -James Seng Andrew Newton wrote: > I'm not sure about the comment regarding a business model. Certainly=20 > none has surfaced in any of the conversations I have heard nor any of=20 > the documents I have seen. >=20 > We should take note of the historical context we have today, and=20 > understand that there are things such as multiple roles (e.g. NOC vs.=20 > abuse) and multiple types of contact (e.g. email vs. civil address), an= d=20 > that with these come the responsibilities that should have been=20 > undertaken on port 43 but never materialized. >=20 > The reason we have CRISP today is that the Internet community=20 > historically did not give port 43 the necessary long view and suddenly=20 > found itself looking back upon a series of wrong turns. Simply ignorin= g=20 > the problem or doing the bare minimum is how it all started. Let us not= =20 > repeat the mistakes of the past so clearly visible today. >=20 > With regard to Patrik's note: I agree. The intent of the draft is not= =20 > to entangle the ENUM group into the finer details of CRISP. It is=20 > simply asking for review by the ENUM working group of a data model to b= e=20 > used by those operators who do have a need for this. And there is no=20 > intent to mandate its use nor to define a single, authoritative model. >=20 > -andy >=20 > James Seng wrote: >=20 >> Personal opinion: >> >> I am trying to stay away from CRISP and if I need to deal with it,=20 >> only with a ten foot pole. The discussion of whois-like information is= =20 >> red-herring, with a presumption business model, that may or may not=20 >> makes sense for ENUM. >> >> In fact, it is not clear to me that it is even applicable to ENUM=20 >> deployment. (Do you really need to provide "registrant" information of= =20 >> a ENUM phone number in public?) >> >> -James Seng >> >> Patrik F=E4ltstr=F6m wrote: >> >>> There has been some side-discussions about what I as chair saw=20 >>> happening with regards to the CRISP/ENUM draft which was presented at= =20 >>> the meeting. >>> >>> My conclusion, after asking Andy and Michael, is that: >>> >>> - The CRISP wg is working on the CRISP architecture, and >>> the ENUM wg is happy "someone else is solving this problem" >>> - The document editors want the ENUM wg to evaluate the >>> data model in the CRISP/ENUM document >>> - There was not consensus whether the document should be >>> added to the charter of the ENUM wg >>> >>> First of all, if people don't agree with my view, send a message to=20 >>> the list. >>> >>> Secondly, I see absolutely no problem with using the ENUM mailing=20 >>> list for discussions about this ENUM/CRISP draft. >>> >>> Richard and myself will check with our AD's what they think about=20 >>> adding this and other documents to the charter. I.e. the overall=20 >>> question for us chairs is what this wg is to do next. >>> >>> Conclusion: This document must be reviewed. The ENUM experts are on=20 >>> the ENUM mailing list. Whether the document is on the charter or not=20 >>> should not make any difference for the existence of the discussion. >>> >>> paf >>> >>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >>> >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enu >> m >=20 >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 06:35:27 2003 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 GAA26277 for ; Fri, 18 Jul 2003 06:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSZp-00006G-RQ for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:35:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAZ158000359 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSZp-00005Q-Bq; Fri, 18 Jul 2003 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSZG-0008Tq-DE for enum@optimus.ietf.org; Fri, 18 Jul 2003 06:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26246 for ; Fri, 18 Jul 2003 06:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSZC-0007aK-00 for enum@ietf.org; Fri, 18 Jul 2003 06:34:22 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19dSZ1-0007Zx-00 for enum@ietf.org; Fri, 18 Jul 2003 06:34:11 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6IAUhk2018066; Fri, 18 Jul 2003 12:30:56 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 12:32:27 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Jul 2003 12:32:26 +0200 Date: Fri, 18 Jul 2003 12:32:24 +0200 Subject: Re: [Enum] CRISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Andrew Newton , enum@ietf.org To: James Seng From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3F17CBBF.10101@pobox.org.sg> Message-Id: <1EA74875-B90B-11D7-84A0-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 18 Jul 2003 10:32:26.0791 (UTC) FILETIME=[E2028B70:01C34D17] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On fredag, jul 18, 2003, at 12:28 Europe/Stockholm, James Seng wrote: > Are you sure we have the capability to review the "data model"? The > use case of ENUM is not even well-defined yet! People which do have testbeds can, I think, most certainly compare the data model in this document with the needs which have been identified in their respective projects. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 06:48:28 2003 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 GAA26500 for ; Fri, 18 Jul 2003 06:48:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSmQ-0000sh-QQ for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAm2fi003369 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 06:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSmP-0000ru-8s; Fri, 18 Jul 2003 06:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSm2-0000rO-Ro for enum@optimus.ietf.org; Fri, 18 Jul 2003 06:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26473 for ; Fri, 18 Jul 2003 06:47:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSly-0007hh-00 for enum@ietf.org; Fri, 18 Jul 2003 06:47:34 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19dSln-0007hG-00 for enum@ietf.org; Fri, 18 Jul 2003 06:47:23 -0400 Received: (qmail 26605 invoked from network); 18 Jul 2003 10:51:57 -0000 Received: from james-fujitsu.ietf57.telekom.at (HELO pobox.org.sg) (81.160.176.129) by sentosa.post1.com with SMTP; 18 Jul 2003 10:51:57 -0000 Message-ID: <3F17D009.9050401@pobox.org.sg> Date: Fri, 18 Jul 2003 18:46:33 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Andrew Newton , enum@ietf.org Subject: Re: [Enum] CRISP References: <1EA74875-B90B-11D7-84A0-000A959CF516@cisco.com> In-Reply-To: <1EA74875-B90B-11D7-84A0-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA26474 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Next question: Why IRIS and not FIRS? (Sorry, obviously I dont follow=20 CRISP enough to know whats the sense there) -James Seng Patrik F=E4ltstr=F6m wrote: >=20 > On fredag, jul 18, 2003, at 12:28 Europe/Stockholm, James Seng wrote: >=20 >> Are you sure we have the capability to review the "data model"? The=20 >> use case of ENUM is not even well-defined yet! >=20 >=20 > People which do have testbeds can, I think, most certainly compare the=20 > data model in this document with the needs which have been identified i= n=20 > their respective projects. >=20 > paf >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 18 07:56:14 2003 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 HAA27700 for ; Fri, 18 Jul 2003 07:56:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dTpx-00030R-Vy for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 07:55:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IBtju1011535 for enum-archive@odin.ietf.org; Fri, 18 Jul 2003 07:55:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dTpF-0002xS-61; Fri, 18 Jul 2003 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dTpC-0002xB-7s for enum@optimus.ietf.org; Fri, 18 Jul 2003 07:54:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27657 for ; Fri, 18 Jul 2003 07:54:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dTpB-0000H7-00 for enum@ietf.org; Fri, 18 Jul 2003 07:54:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19dTp0-0000Gn-00 for enum@ietf.org; Fri, 18 Jul 2003 07:54:46 -0400 Subject: RE: [Enum] CRISP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 18 Jul 2003 13:58:15 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <06CF906FE3998C4E944213062009F1620E9FD3@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Enum] CRISP Thread-Index: AcNNGrYjp0xrDdGwQBCkwJRMPeM25AACCAJA From: "Stastny Richard" To: "James Seng" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Andrew Newton" , Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable James seng wrote: >=20 > Next question: Why IRIS and not FIRS? (Sorry, obviously I=20 > dont follow=20 > CRISP enough to know whats the sense there) >=20 Aha, so could you please move over this discussion to the crisp mailing list. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 19 11:14:29 2003 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 LAA16458 for ; Sat, 19 Jul 2003 11:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtPN-00024c-TU for enum-archive@odin.ietf.org; Sat, 19 Jul 2003 11:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6JFE1LD007955 for enum-archive@odin.ietf.org; Sat, 19 Jul 2003 11:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtOO-0001zv-12; Sat, 19 Jul 2003 11:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dtOD-0001zd-Bx for enum@optimus.ietf.org; Sat, 19 Jul 2003 11:12:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16386 for ; Sat, 19 Jul 2003 11:12:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dtOC-0002ig-00 for enum@ietf.org; Sat, 19 Jul 2003 11:12:48 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19dtO1-0002ib-00 for enum@ietf.org; Sat, 19 Jul 2003 11:12:37 -0400 Received: (qmail 45000 invoked from network); 19 Jul 2003 15:16:36 -0000 Received: from unknown (HELO pobox.org.sg) (193.80.99.103) by sentosa.post1.com with SMTP; 19 Jul 2003 15:16:36 -0000 Message-ID: <3F195F95.7050906@pobox.org.sg> Date: Sat, 19 Jul 2003 23:11:17 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Stastny Richard CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Andrew Newton , enum@ietf.org Subject: Re: [Enum] CRISP References: <06CF906FE3998C4E944213062009F1620E9FD3@oefeg-s02.oefeg.loc> In-Reply-To: <06CF906FE3998C4E944213062009F1620E9FD3@oefeg-s02.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, I am happy to move all discussion of CRISP to CRISP mailing list. Thank you. -James Seng Stastny Richard wrote: > James seng wrote: > >>Next question: Why IRIS and not FIRS? (Sorry, obviously I >>dont follow >>CRISP enough to know whats the sense there) >> > > Aha, so could you please move over this discussion to the > crisp mailing list. > > Richard > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sun Jul 20 12:21:22 2003 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 MAA22181 for ; Sun, 20 Jul 2003 12:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eGvg-0003q4-TE for enum-archive@odin.ietf.org; Sun, 20 Jul 2003 12:20:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KGKuf5014748 for enum-archive@odin.ietf.org; Sun, 20 Jul 2003 12:20:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eGun-0003nK-Ae; Sun, 20 Jul 2003 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eGuf-0003mq-Ts for enum@optimus.ietf.org; Sun, 20 Jul 2003 12:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22177 for ; Sun, 20 Jul 2003 12:19:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eGue-0003MG-00 for enum@ietf.org; Sun, 20 Jul 2003 12:19:52 -0400 Received: from [216.93.164.123] (helo=zak.ecotroph.net) by ietf-mx with esmtp (Exim 4.12) id 19eGuT-0003MD-00 for enum@ietf.org; Sun, 20 Jul 2003 12:19:42 -0400 Received: from ecotroph.net (64-83-8-178-nova-dsl.cavtel.net [::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Sun, 20 Jul 2003 12:19:24 -0400 Message-ID: <3F1AC106.90009@ecotroph.net> Date: Sun, 20 Jul 2003 12:19:18 -0400 From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Seng CC: "=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=" , enum@ietf.org Subject: Re: [Enum] CRISP References: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> <3F17B725.4020104@pobox.org.sg> <3F17BF0F.7070501@ecotroph.net> <3F17CBBF.10101@pobox.org.sg> In-Reply-To: <3F17CBBF.10101@pobox.org.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James Seng wrote: > > This is not to say all information is useless. I certainly cant disagree > with Patrik to put ENUM service provider information available because > it helps in operation. Then I am not sure how this is a disagreement. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 21 05:36:39 2003 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 FAA22053 for ; Mon, 21 Jul 2003 05:36:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX5Z-0005qc-U5 for enum-archive@odin.ietf.org; Mon, 21 Jul 2003 05:36:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L9aDvM022474 for enum-archive@odin.ietf.org; Mon, 21 Jul 2003 05:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX4P-0005lk-Ap; Mon, 21 Jul 2003 05:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eX4E-0005lM-3F for enum@optimus.ietf.org; Mon, 21 Jul 2003 05:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22032 for ; Mon, 21 Jul 2003 05:34:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eX4A-0001J0-00 for enum@ietf.org; Mon, 21 Jul 2003 05:34:46 -0400 Received: from internal.mail.demon.net ([193.195.224.3]) by ietf-mx with esmtp (Exim 4.12) id 19eX40-0001IF-00 for enum@ietf.org; Mon, 21 Jul 2003 05:34:36 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id h6L9YbP02853; Mon, 21 Jul 2003 09:34:41 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 19eX2i-000IJb-00; Mon, 21 Jul 2003 10:33:16 +0100 Date: Mon, 21 Jul 2003 10:33:16 +0100 From: "Clive D.W. Feather" To: James Seng Cc: Andrew Newton , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , enum@ietf.org Subject: Re: [Enum] CRISP Message-ID: <20030721093316.GA70062@finch-staff-1.thus.net> References: <34E0686C-B8F8-11D7-84A0-000A959CF516@cisco.com> <3F17B725.4020104@pobox.org.sg> <3F17BF0F.7070501@ecotroph.net> <3F17CBBF.10101@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F17CBBF.10101@pobox.org.sg> User-Agent: Mutt/1.5.3i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , James Seng said: > The assumption that people actually wants to put their private > information available in some database to access does not makes sense to > me. [...] > The other reasons I am against the work is because we have very little > operational experiences (on the whole) to actually know what info we > want to put in public and whats not. Many of us are in the EU. This whois information is a reverse telephone directory to which Directive 2002/58/EC applies. Article 12 reads in part: 2. Member States shall ensure that subscribers are given the opportunity to determine whether their personal data are included in a public directory, and if so, which, to the extent that such data are relevant for the purpose of the directory as determined by the provider of the directory, and to verify, correct or withdraw such data. Not being included in a public subscriber directory, verifying, correcting or withdrawing personal data from it shall be free of charge. 3. Member States may require that for any purpose of a public directory other than the search of contact details of persons on the basis of their name and, where necessary, a minimum of other identifiers, additional consent be asked of the subscribers. 4. Paragraphs 1 and 2 shall apply to subscribers who are natural persons. Member States shall also ensure, in the framework of Community law and applicable national legislation, that the legitimate interests of subscribers other than natural persons with regard to their entry in public directories are sufficiently protected. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 09:34:21 2003 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 JAA12214 for ; Wed, 23 Jul 2003 09:34:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJkf-0001K0-S8 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 09:33:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDXr7I005079 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 09:33:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJjp-0001HR-Pv; Wed, 23 Jul 2003 09:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJjl-0001H2-FZ for enum@optimus.ietf.org; Wed, 23 Jul 2003 09:32:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12166 for ; Wed, 23 Jul 2003 09:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJjj-0004h7-00 for enum@ietf.org; Wed, 23 Jul 2003 09:32:55 -0400 Received: from rainier.illuminet.com ([12.41.110.52]) by ietf-mx with esmtp (Exim 4.12) id 19fJjY-0004gl-00 for enum@ietf.org; Wed, 23 Jul 2003 09:32:44 -0400 Received: from oly1wnexc02.corp.illuminet.com (oly1wnexc02.corp.illuminet.com [10.55.13.13]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id GAA19867; Wed, 23 Jul 2003 06:30:37 -0700 (PDT) Received: from oly1wnexc01.corp.illuminet.com ([10.55.13.12]) by oly1wnexc02.corp.illuminet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N99YKPCY; Wed, 23 Jul 2003 06:30:37 -0700 Received: by oly1wnexc01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 06:30:37 -0700 Message-ID: <318266A4431BC549B4C4D6FD3EA6E24D012CE64B@ove1wnexm01.corp.illuminet.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "McCandless, Kevin" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] CRISP Date: Wed, 23 Jul 2003 06:30:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here are my thoughts. WHOIS is unacceptable for ENUM implementation within the US. We need = an alternative based on feedback from organization such as EPIC and = FTC. I would like the ENUM working group to accept IRIS as a working = group item. Why because we need other options for ENUM registrars to = store only minimum amount of information related to the registrant and = to help ensure their privacy. Even though CRISP may work this in = parallel they have a large battle in front of them if they want to use = IRIS as a replacement for WHOIS for the domain name registrars. This = will become a religious battle within a five letter organization. So, = we can avoid this by being very specific as the use for IRIS as it = related to ENUM and stay away from the broader debates! K...... > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Friday, July 18, 2003 3:17 AM > To: enum@ietf.org > Subject: [Enum] CRISP >=20 >=20 > There has been some side-discussions about what I as chair saw=20 > happening with regards to the CRISP/ENUM draft which was presented at = > the meeting. >=20 > My conclusion, after asking Andy and Michael, is that: >=20 > - The CRISP wg is working on the CRISP architecture, and > the ENUM wg is happy "someone else is solving this problem" > - The document editors want the ENUM wg to evaluate the > data model in the CRISP/ENUM document > - There was not consensus whether the document should be > added to the charter of the ENUM wg >=20 > First of all, if people don't agree with my view, send a=20 > message to the=20 > list. >=20 > Secondly, I see absolutely no problem with using the ENUM=20 > mailing list=20 > for discussions about this ENUM/CRISP draft. >=20 > Richard and myself will check with our AD's what they think about=20 > adding this and other documents to the charter. I.e. the overall=20 > question for us chairs is what this wg is to do next. >=20 > Conclusion: This document must be reviewed. The ENUM experts=20 > are on the=20 > ENUM mailing list. Whether the document is on the charter or=20 > not should=20 > not make any difference for the existence of the discussion. >=20 > paf >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 10:13:30 2003 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 KAA14252 for ; Wed, 23 Jul 2003 10:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKMZ-0003hZ-O6 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 10:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NED3hf014185 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 10:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKMX-0003gJ-FL; Wed, 23 Jul 2003 10:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKMD-0003fz-GZ for enum@optimus.ietf.org; Wed, 23 Jul 2003 10:12:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14173 for ; Wed, 23 Jul 2003 10:12:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKMB-0004xT-00 for enum@ietf.org; Wed, 23 Jul 2003 10:12:39 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19fKM0-0004wt-00 for enum@ietf.org; Wed, 23 Jul 2003 10:12:28 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 97F65137F1B; Wed, 23 Jul 2003 07:10:07 -0700 (PDT) To: "McCandless, Kevin" Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: Re: [Enum] CRISP In-Reply-To: Message from "McCandless, Kevin" of "Wed, 23 Jul 2003 06:30:36 PDT." <318266A4431BC549B4C4D6FD3EA6E24D012CE64B@ove1wnexm01.corp.illuminet.com> Date: Wed, 23 Jul 2003 07:10:07 -0700 Message-ID: <58814.1058969407@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I'm happy for this WG to consider the applicability of the CRISP to ENUM. Though personally I doubt if it would be applicable. It will be fun to find out though. Like you, I think a whois-based solution is unacceptable. Just wondering: how often is whois actually used for something that's operationally useful? Do the DNS Delegation Police ever use the whois contact data when they come across dead or lame name servers? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 11:01:34 2003 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 LAA16080 for ; Wed, 23 Jul 2003 11:01:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fL76-0005tU-HA for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 11:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NF18no022637 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 11:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fL6z-0005si-B1; Wed, 23 Jul 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fL6r-0005sB-At for enum@optimus.ietf.org; Wed, 23 Jul 2003 11:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16053 for ; Wed, 23 Jul 2003 11:00:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fL6o-0005HW-00 for enum@ietf.org; Wed, 23 Jul 2003 11:00:50 -0400 Received: from centr-svr.org ([217.160.143.182]) by ietf-mx with esmtp (Exim 4.12) id 19fL6e-0005HL-00 for enum@ietf.org; Wed, 23 Jul 2003 11:00:40 -0400 Received: from centr.org (localhost.localdomain [127.0.0.1]) by centr-svr.org (Postfix) with ESMTP id 231E03FA0A5; Wed, 23 Jul 2003 15:00:18 +0000 (UTC) Message-ID: <3F1EA2EB.1040904@centr.org> Date: Wed, 23 Jul 2003 16:59:55 +0200 From: Kim Davies Organization: Council of European National Top-Level Domain Registries User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McCandless, Kevin" , enum@ietf.org Subject: Re: [Enum] CRISP References: <318266A4431BC549B4C4D6FD3EA6E24D012CE64B@ove1wnexm01.corp.illuminet.com> In-Reply-To: <318266A4431BC549B4C4D6FD3EA6E24D012CE64B@ove1wnexm01.corp.illuminet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit McCandless, Kevin wrote: > Here are my thoughts. > > WHOIS is unacceptable for ENUM implementation within the US. We need an alternative based on feedback from organization such as EPIC and FTC. I would like the ENUM working group to accept IRIS as a working group item. Why because we need other options for ENUM registrars to store only minimum amount of information related to the registrant and to help ensure their privacy. Even though CRISP may work this in parallel they have a large battle in front of them if they want to use IRIS as a replacement for WHOIS for the domain name registrars. This will become a religious battle within a five letter organization. So, we can avoid this by being very specific as the use for IRIS as it related to ENUM and stay away from the broader debates! It seems a little presumptuous to introduce IRIS as a work item into the ENUM group when it might not be the ultimate protocol coming out of the CRISP working group. I'd rather see any considerations be protocol neutral at this stage, so the possibility of the two groups arriving at two different protocols is removed. kim _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 11:29:29 2003 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 LAA16934 for ; Wed, 23 Jul 2003 11:29:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLY6-0007Hf-0R for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 11:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NFT11k027982 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLY4-0007Gt-9W; Wed, 23 Jul 2003 11:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLXa-0007GG-F9 for enum@optimus.ietf.org; Wed, 23 Jul 2003 11:28:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16863 for ; Wed, 23 Jul 2003 11:28:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fLXZ-0005Sg-00 for enum@ietf.org; Wed, 23 Jul 2003 11:28:29 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19fLXO-0005S0-00 for enum@ietf.org; Wed, 23 Jul 2003 11:28:18 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 4CD7B137F4B; Wed, 23 Jul 2003 08:27:00 -0700 (PDT) To: Kim Davies Cc: "McCandless, Kevin" , enum@ietf.org Subject: Re: [Enum] CRISP In-Reply-To: Message from Kim Davies of "Wed, 23 Jul 2003 16:59:55 +0200." <3F1EA2EB.1040904@centr.org> Date: Wed, 23 Jul 2003 08:27:00 -0700 Message-ID: <59833.1058974020@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Kim" == Kim Davies writes: Kim> It seems a little presumptuous to introduce IRIS as a work Kim> item into the ENUM group when it might not be the ultimate Kim> protocol coming out of the CRISP working group. I'd rather Kim> see any considerations be protocol neutral at this stage, so Kim> the possibility of the two groups arriving at two different Kim> protocols is removed. Indeed. However it's possible that the deliberations on CRISP issues as they pertain to ENUM could inform the protocol development that gets done in the CRISP WG. And just to avoid any misunderstanding, I presume you're not implying this WG should develop its own protocol or duplicate what goes on in the CRISP WG? You might recall when I suggested this WG looked at DNSSEC, some people mistakenly thought I wanted the group to get into the politics of who held what key or RR formats and packet headers. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 13:18:38 2003 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 NAA20233 for ; Wed, 23 Jul 2003 13:18:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNFj-0004Ce-Ax for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 13:18:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NHIBPK016139 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 13:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNFZ-0004Bp-OG; Wed, 23 Jul 2003 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fNEj-0004AD-0U for enum@optimus.ietf.org; Wed, 23 Jul 2003 13:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20198 for ; Wed, 23 Jul 2003 13:17:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fNEh-0006Fk-00 for enum@ietf.org; Wed, 23 Jul 2003 13:17:07 -0400 Received: from [216.93.164.123] (helo=zak.ecotroph.net) by ietf-mx with esmtp (Exim 4.12) id 19fNEW-0006Fh-00 for enum@ietf.org; Wed, 23 Jul 2003 13:16:56 -0400 Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Wed, 23 Jul 2003 13:16:45 -0400 Message-ID: <3F1EC885.2000902@ecotroph.net> Date: Wed, 23 Jul 2003 13:40:21 -0400 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kim Davies CC: "McCandless, Kevin" , enum@ietf.org Subject: Re: [Enum] CRISP References: <318266A4431BC549B4C4D6FD3EA6E24D012CE64B@ove1wnexm01.corp.illuminet.com> <3F1EA2EB.1040904@centr.org> In-Reply-To: <3F1EA2EB.1040904@centr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kim Davies wrote: > > > It seems a little presumptuous to introduce IRIS as a work item into the > ENUM group when it might not be the ultimate protocol coming out of the > CRISP working group. I'd rather see any considerations be protocol > neutral at this stage, so the possibility of the two groups arriving at > two different protocols is removed. After the CRISP meeting in Vienna, it is not presuming much. However, that doesn't stop us from doing a simple requirements document that is protocol neutral. Would that be better first step? Would people be more comfortable with this approach? -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Wed Jul 23 17:15:15 2003 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 RAA03125 for ; Wed, 23 Jul 2003 17:15:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQwi-0007Pw-6h for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 17:14:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLEmcX028485 for enum-archive@odin.ietf.org; Wed, 23 Jul 2003 17:14:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQvx-0007JL-KE; Wed, 23 Jul 2003 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQvn-0007Ia-Ld for enum@optimus.ietf.org; Wed, 23 Jul 2003 17:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03103 for ; Wed, 23 Jul 2003 17:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQvl-0000s3-00 for enum@ietf.org; Wed, 23 Jul 2003 17:13:49 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fQva-0000ri-00 for enum@ietf.org; Wed, 23 Jul 2003 17:13:38 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6NLAqkR012417; Wed, 23 Jul 2003 23:10:54 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 23:13:01 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 23:13:01 +0200 Date: Wed, 23 Jul 2003 23:12:54 +0200 Subject: Re: [Enum] CRISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "McCandless, Kevin" , enum@ietf.org To: Jim Reid From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <58814.1058969407@shell.nominum.com> Message-Id: <6CD2024E-BD52-11D7-84A0-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 23 Jul 2003 21:13:01.0611 (UTC) FILETIME=[330367B0:01C3515F] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On onsdag, jul 23, 2003, at 16:10 Europe/Stockholm, Jim Reid wrote: > Do the DNS Delegation Police ever use the whois > contact data when they come across dead or lame name servers? I use whois in DNS-problematic cases. When the SOA information is "not enough" (doesn't lead to anything). Last when trying to save a very-broken-TLD and undo-this-transfer-of-domain-between-registrars-please situation when all admin/tech info was the old, but only the domain name holder (and registrar) had changed. As I stated in a mail some time ago...in Sweden we are interested in a CRISP-like function where it is possible to know _to_who_ a delegation in the ENUM tree of +46 is supposed to go. It is very good to have both the map and the reality, because when they differ, one of them is wrong. Note, I am _NOT_ talking about having registrant information in this system I talk about. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 03:43:19 2003 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 DAA27561 for ; Thu, 24 Jul 2003 03:43:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fakW-0001mC-5l for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 03:42:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O7gq7G006782 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 03:42:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fajh-0001gW-BX; Thu, 24 Jul 2003 03:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fajD-0001bO-Hf for enum@optimus.ietf.org; Thu, 24 Jul 2003 03:41:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27498 for ; Thu, 24 Jul 2003 03:41:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fajB-00040Y-00 for enum@ietf.org; Thu, 24 Jul 2003 03:41:29 -0400 Received: from smtp.denic.de ([194.246.96.22]) by ietf-mx with esmtp (Exim 4.12) id 19faj0-000403-00 for enum@ietf.org; Thu, 24 Jul 2003 03:41:18 -0400 Received: from w4.denic.de ([194.246.96.15]) by smtp.denic.de with esmtp id 19faiU-0003bf-00; Thu, 24 Jul 2003 09:40:46 +0200 Subject: Re: Re: [Enum] CRISP To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= Cc: enum@ietf.org, Jim.Reid@nominum.com, KMcCandless@verisign.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Sabine Dolderer/Denic Date: Thu, 24 Jul 2003 09:31:38 +0200 X-MIMETrack: Serialize by Router on notes/Denic(601CF1HF55 | May 13, 2003) at 24.07.2003 09:40:46 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Patrik, On 23.07.2003 23:12 Patrik F=E4ltstr=F6m wrote: > > > On onsdag, jul 23, 2003, at 16:10 Europe/Stockholm, Jim Reid wrote: > > > Do the DNS Delegation Police ever use the whois > > contact data when they come across dead or lame name servers? > > I use whois in DNS-problematic cases. When the SOA information is "no= t > enough" (doesn't lead to anything). > > Last when trying to save a very-broken-TLD and > undo-this-transfer-of-domain-between-registrars-please situation when= > all admin/tech info was the old, but only the domain name holder (and= > registrar) had changed. > > As I stated in a mail some time ago...in Sweden we are interested in = a > CRISP-like function where it is possible to know _to_who_ a delegatio= n > in the ENUM tree of +46 is supposed to go. It is very good to have bo= th > the map and the reality, because when they differ, one of them is wro= ng. > > Note, I am _NOT_ talking about having registrant information in this > system I talk about. just for clarification. Which data you plan to publish in the Swedish enum trial via whois/cris= p - the holder of the enum domain/e.164 number =3D registrant? or - the maintainer of the nameserver to whom the enum domain is delegated= ? and if the second case is true. Only the information for the primary dn= s (how do you identify them) or all nameservers of the delegation? And which information for all cases exactly (name, address, phone, fax,= email, ...) Sabine > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > Viele Gr=FC=DFe Sabine Dolderer -- Sabine Dolderer DENIC eG Wiesenh=FCttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer@denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 05:13:34 2003 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 FAA00038 for ; Thu, 24 Jul 2003 05:13:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc9s-0006oW-G2 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9D8L5026170 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc9l-0006nj-Dp; Thu, 24 Jul 2003 05:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fc9J-0006nX-PF for enum@optimus.ietf.org; Thu, 24 Jul 2003 05:12:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00016 for ; Thu, 24 Jul 2003 05:12:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fc9G-0004c8-00 for enum@ietf.org; Thu, 24 Jul 2003 05:12:30 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19fc95-0004c2-00 for enum@ietf.org; Thu, 24 Jul 2003 05:12:20 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6O98ouf012369; Thu, 24 Jul 2003 11:09:03 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 11:11:12 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 11:11:11 +0200 Date: Thu, 24 Jul 2003 11:11:04 +0200 Subject: Re: [Enum] CRISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org, Jim.Reid@nominum.com, KMcCandless@verisign.com To: Sabine Dolderer/Denic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 24 Jul 2003 09:11:11.0242 (UTC) FILETIME=[866F4EA0:01C351C3] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On torsdag, jul 24, 2003, at 09:31 Europe/Stockholm, Sabine Dolderer/Denic wrote: > just for clarification. > > Which data you plan to publish in the Swedish enum trial via > whois/crisp > > - the holder of the enum domain/e.164 number = registrant? No. I don't think so. > - the maintainer of the nameserver to whom the enum domain is > delegated? Yes. > and if the second case is true. Only the information for the primary > dns > (how do you identify them) or all nameservers of the delegation? I don't know yet. We are exactly at the point in the project where things like this is discussed. > And which information for all cases exactly (name, address, phone, fax, > email, ...) I have no idea. I think the project will look at what is stored today in DNS for DNS operations, and start with that. But, I am only one of many participants in the Swedish ENUM trial. I am happy to continue to report our findings. The only thing I know of so far is that it is interesting (operationally) to know what parties are involved. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 05:27:28 2003 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 FAA00193 for ; Thu, 24 Jul 2003 05:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcNL-0007Di-6z for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9R3dv027708 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcNK-0007CW-3K; Thu, 24 Jul 2003 05:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcN9-0007By-O3 for enum@optimus.ietf.org; Thu, 24 Jul 2003 05:26:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00186 for ; Thu, 24 Jul 2003 05:26:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcN6-0004h7-00 for enum@ietf.org; Thu, 24 Jul 2003 05:26:48 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19fcMv-0004gl-00 for enum@ietf.org; Thu, 24 Jul 2003 05:26:37 -0400 Received: (qmail 12184 invoked from network); 24 Jul 2003 09:42:10 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 24 Jul 2003 09:42:10 -0000 Message-ID: <3F1FA600.9070103@pobox.org.sg> Date: Thu, 24 Jul 2003 17:25:20 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Sabine Dolderer/Denic , enum@ietf.org, Jim.Reid@nominum.com, KMcCandless@verisign.com Subject: Re: [Enum] CRISP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA00187 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Patrik F=E4ltstr=F6m wrote: > On torsdag, jul 24, 2003, at 09:31 Europe/Stockholm, Sabine=20 > Dolderer/Denic wrote: >=20 >> just for clarification. >> >> Which data you plan to publish in the Swedish enum trial via whois/cri= sp >> >> - the holder of the enum domain/e.164 number =3D registrant? >=20 > No. I don't think so. Agree. >> - the maintainer of the nameserver to whom the enum domain is delegate= d? >=20 > Yes. Disagree. I dont think this should be publish. Ask the CC registry if=20 you need the info. What we do need is the WHOIS/IRIS info for the CC registry which is=20 already published in RIPE-NCC. -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 05:57:28 2003 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 FAA00911 for ; Thu, 24 Jul 2003 05:57:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcqO-0000WA-9k for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O9v4Qa001944 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 05:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcqL-0000Uc-6y; Thu, 24 Jul 2003 05:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcpl-0000UD-6t for enum@optimus.ietf.org; Thu, 24 Jul 2003 05:56:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00888 for ; Thu, 24 Jul 2003 05:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fcph-0004tj-00 for enum@ietf.org; Thu, 24 Jul 2003 05:56:21 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19fcpW-0004tT-00 for enum@ietf.org; Thu, 24 Jul 2003 05:56:11 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 2B338137F15; Thu, 24 Jul 2003 02:55:13 -0700 (PDT) To: James Seng Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Sabine Dolderer/Denic , enum@ietf.org, KMcCandless@verisign.com Subject: Re: [Enum] CRISP In-Reply-To: Message from James Seng of "Thu, 24 Jul 2003 17:25:20 +0800." <3F1FA600.9070103@pobox.org.sg> Date: Thu, 24 Jul 2003 02:55:13 -0700 Message-ID: <98323.1059040513@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "James" == James Seng writes: >>> - the maintainer of the nameserver to whom the enum domain is >>> delegate=d >> =20 Yes. James> Disagree. I dont think this should be publish. Ask the CC James> registry if=20 you need the info. This may not be possible. It assumes the Tier-1 registry holds that info. [Let's use the ETSI terminology to avoid confusion with ccTLD operators.] That registry might not have delegated a number to an end user. There could be intermediate delegations: eg DDI blocks for a large company or operator-specific chunks of the number space. Maybe there is a discrete registry for a given area code, etc, etc. James> What we do need is the WHOIS/IRIS info for the CC registry James> which is=20 already published in RIPE-NCC. Who's "we"? Even without RIPE's whois server this information can be obtained, albeit in a painful way. ITU can point you at the official ENUM contact for a National Administration. That official will be able to identify the technical contact for the Tier-1 registry. Or identify someone who can do that. BTW, Patrik's recent remarks aside, nobody has yet come forward with reasons or justifications for whois/crisp for ENUM. And I've still to see any data which shows how often existing whois data -- not necessarily under e164.arpa! -- is accessed to solve operational issues. I would really like this WG answer the question "do we have a real need for whois/crisp/whatever?" before jumping headlong into a whole bunch of nasty issues like data protection, privacy, protocol holy wars and so on. Where are the Delegation Police and how much reliance do they have on whois? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 06:09:27 2003 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 GAA01122 for ; Thu, 24 Jul 2003 06:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fd1y-0001SB-Iq for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 06:09:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OA92we005569 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 06:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fd1x-0001RS-D0; Thu, 24 Jul 2003 06:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fd1I-0001NL-QU for enum@optimus.ietf.org; Thu, 24 Jul 2003 06:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01109 for ; Thu, 24 Jul 2003 06:08:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fd1F-0004y1-00 for enum@ietf.org; Thu, 24 Jul 2003 06:08:17 -0400 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by ietf-mx with esmtp (Exim 4.12) id 19fd14-0004xk-00 for enum@ietf.org; Thu, 24 Jul 2003 06:08:06 -0400 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id h6OA7kb03819; Thu, 24 Jul 2003 12:07:46 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h6OA7kL29751; Thu, 24 Jul 2003 12:07:46 +0200 (MEST) Message-Id: <200307241007.h6OA7kL29751@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Jim Reid Cc: enum@ietf.org Subject: Re: [Enum] CRISP In-reply-to: Your message of "Thu, 24 Jul 2003 02:55:13 PDT." <98323.1059040513@shell.nominum.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Thu, 24 Jul 2003 12:07:45 +0200 From: Peter Koch Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > holy wars and so on. Where are the Delegation Police and how much > reliance do they have on whois? not being part of that Department, but sometimes hunting down DNS problems, occasionally even on an automated base, I'd rather use the whois data from the address registry than that from the domain name registry. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 07:29:37 2003 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 HAA02345 for ; Thu, 24 Jul 2003 07:29:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19feHW-00053h-02 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 07:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OBT9NY019434 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 07:29:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19feHN-000534-IB; Thu, 24 Jul 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19feGs-00052p-RF for enum@optimus.ietf.org; Thu, 24 Jul 2003 07:28:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02321 for ; Thu, 24 Jul 2003 07:28:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19feGs-0005Ib-00 for enum@ietf.org; Thu, 24 Jul 2003 07:28:30 -0400 Received: from ams-msg-core-1.cisco.com ([144.254.74.60]) by ietf-mx with esmtp (Exim 4.12) id 19feGh-0005IH-00 for enum@ietf.org; Thu, 24 Jul 2003 07:28:19 -0400 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h6OBP0wq008863; Thu, 24 Jul 2003 13:25:01 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 13:27:10 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 13:27:09 +0200 Date: Thu, 24 Jul 2003 13:27:00 +0200 Subject: Re: [Enum] CRISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: James Seng , Sabine Dolderer/Denic , enum@ietf.org, KMcCandless@verisign.com To: Jim Reid From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <98323.1059040513@shell.nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 24 Jul 2003 11:27:09.0372 (UTC) FILETIME=[850F27C0:01C351D6] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On torsdag, jul 24, 2003, at 11:55 Europe/Stockholm, Jim Reid wrote: >>>> - the maintainer of the nameserver to whom the enum domain is >>>> delegate=d >>> =20 Yes. > > James> Disagree. I dont think this should be publish. Ask the CC > James> registry if=20 you need the info. How are you supposed to ask the Tier-1 registry? This is exactly where (from my point of view) CRISP comes into play. > James> What we do need is the WHOIS/IRIS info for the CC registry > James> which is=20 already published in RIPE-NCC. > > Who's "we"? > > Even without RIPE's whois server this information can be obtained, > albeit in a painful way. ITU can point you at the official ENUM > contact for a National Administration. That official will be able to > identify the technical contact for the Tier-1 registry. Or identify > someone who can do that. But, how do you send the query to whoever? Call him via the phone? Send postcard? Just because ENUM involve so many players, it might be interesting to know, for operational reasons, who the player in question is. > BTW, Patrik's recent remarks aside, nobody has yet come forward with > reasons or justifications for whois/crisp for ENUM. And I've still to > see any data which shows how often existing whois data -- not > necessarily under e164.arpa! -- is accessed to solve operational > issues. As I said, I have rescued one registrant in the .com domain, and one TLD (will not disclose which) during the last 2 months with the help from Whois data. That is just one example. > I would really like this WG answer the question "do we have a > real need for whois/crisp/whatever?" before jumping headlong into a > whole bunch of nasty issues like data protection, privacy, protocol > holy wars and so on. Where are the Delegation Police and how much > reliance do they have on whois? "Whois" (the service) is the only place where one can get to know the admin and technical contact for a domain. In DNS you only see the technical contact, and possibly not even that. You only see some information about the one which runs the DNS for the zone. Just seeing (if you can get the SOA in the first place) what the SOA is for the zone or parent is definitely not enough for operations of something as important as DNS. One really want to know the admin contact. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Thu Jul 24 07:50:30 2003 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 HAA02851 for ; Thu, 24 Jul 2003 07:50:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19febj-0006aN-Az for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 07:50:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OBo3HB025304 for enum-archive@odin.ietf.org; Thu, 24 Jul 2003 07:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19febh-0006Zl-SC; Thu, 24 Jul 2003 07:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19febg-0006ZL-5E for enum@optimus.ietf.org; Thu, 24 Jul 2003 07:50:00 -0400 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02815 for ; Thu, 24 Jul 2003 07:49:56 -0400 (EDT) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 47EE4137F23; Thu, 24 Jul 2003 04:44:28 -0700 (PDT) To: Peter Koch Cc: enum@ietf.org Subject: Re: [Enum] CRISP In-Reply-To: Your message of "Thu, 24 Jul 2003 12:07:45 +0200." <200307241007.h6OA7kL29751@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 24 Jul 2003 04:44:28 -0700 Message-ID: <99648.1059047068@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Peter" == Peter Koch writes: >> holy wars and so on. Where are the Delegation Police and how >> much reliance do they have on whois? Peter> not being part of that Department, but sometimes hunting Peter> down DNS problems, occasionally even on an automated base, Peter> I'd rather use the whois data from the address registry Peter> than that from the domain name registry. Me too. People have more of an incentive to make sure their address contact data at the RIR is correct and up to date. But how often is "sometimes" and is it reasonable to assume that an ENUM whois would be accessed so frequently? [Maybe it'd be more, maybe less. Who knows?] I suspect there will be little need for whois in ENUM because the zone files and name servers will generally be in the hands of competent people. However it would be better to have some real data instead of a gut feel. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Fri Jul 25 01:25:20 2003 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 BAA12184 for ; Fri, 25 Jul 2003 01:25:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fv4X-00088X-1l for enum-archive@odin.ietf.org; Fri, 25 Jul 2003 01:24:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P5OrPR031242 for enum-archive@odin.ietf.org; Fri, 25 Jul 2003 01:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fv3g-00082B-No; Fri, 25 Jul 2003 01:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fv2m-00081g-TD for enum@optimus.ietf.org; Fri, 25 Jul 2003 01:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12148 for ; Fri, 25 Jul 2003 01:23:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fv2j-000569-00 for enum@ietf.org; Fri, 25 Jul 2003 01:23:02 -0400 Received: from sentosa.post1.com ([202.27.17.100]) by ietf-mx with smtp (Exim 4.12) id 19fv2Y-00055d-00 for enum@ietf.org; Fri, 25 Jul 2003 01:22:50 -0400 Received: (qmail 26427 invoked from network); 25 Jul 2003 05:38:18 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 25 Jul 2003 05:38:18 -0000 Message-ID: <3F20BE5C.7060609@pobox.org.sg> Date: Fri, 25 Jul 2003 13:21:32 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Jim Reid , Sabine Dolderer/Denic , enum@ietf.org, KMcCandless@verisign.com Subject: Re: [Enum] CRISP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > How are you supposed to ask the Tier-1 registry? This is exactly where > (from my point of view) CRISP comes into play. Email, Phone, or Snail Mail and a justification for the info you need. -James Seng _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Sat Jul 26 15:06:22 2003 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 PAA15576 for ; Sat, 26 Jul 2003 15:06:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gUMF-0001IN-4B for enum-archive@odin.ietf.org; Sat, 26 Jul 2003 15:05:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6QJ5Vev004974 for enum-archive@odin.ietf.org; Sat, 26 Jul 2003 15:05:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gULk-0001GE-Rw; Sat, 26 Jul 2003 15:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8bT-0006yf-Av for enum@optimus.ietf.org; Fri, 25 Jul 2003 15:52:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20053 for ; Fri, 25 Jul 2003 15:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8bR-0003Oc-00 for enum@ietf.org; Fri, 25 Jul 2003 15:51:45 -0400 Received: from smtp-02.inode.at ([62.99.194.4] helo=smtp.inode.at) by ietf-mx with esmtp (Exim 4.12) id 19g8bP-0003OK-00 for enum@ietf.org; Fri, 25 Jul 2003 15:51:44 -0400 Received: from ap1.stiwoll.mah.priv.at ([62.99.233.53]:29151 helo=mah9.eunet.at) by smtp.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 19g8bB-0008VE-00; Fri, 25 Jul 2003 21:51:29 +0200 Message-Id: <5.2.0.9.2.20030725205421.041238a8@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Jul 2003 21:49:36 +0200 To: ga@centr.org, enum-trial@lists.nic.at, enum@ietf.org, mitglieder@ispa.at, ronald@schwaerzler.com, franz@schmidbauer.at, christian.singer@bmvit.gv.at, ernst.langmantel@rtr.at, naseem@internic.at, cm@tahina.priv.at, Dennis.Jennings@4thLevelVentures.ie, "IPA Stiftungsrat":;, "IPA Vorstand":;, hermann.steinringer@univie.ac.at, franz.kroepfl@a1.net, "Erik Lagerway" , stone , vito@mail.bcmtwn.com, "Jan-Olof" , mierla@fokus.fraunhofer.de, Wimmreuter Wilhelm , Mark Spencer , richard.wein@nic.at, schischka@nic.at, alan.duric@globalipsound.com, hotta@jprs.co.jp, k.krenn@conova.com, karl.bonomeo@softcom.co.at, berner@peak.at, christian.crha@colt.at, Christoph.Schoeller@colt.at, Max.Haidenthaler@colt.at, md@bts.sk, binder@cvtstu.cvt.stuba.sk, m.ermert@gmx.de, "Ernst Langmantel" , georg.serentschy@rtr.at, osten.franberg@lme.ercisson.se, dan@jasomi.com, eva.frolich@neustar.com, paul@lanifex.com, michael Kofler , burgi@salomon.at, richard.hill@itu.int, jeanette@medea.wz-berlin.de, shl@nic-se.se, stefan@nic-se.se, mm@bacher.at, Mark S Petrovic , David Beckemeyer , Peter A Porzer , csch@Kiez.NET, anne.troye@cec.eu.int, george.papapavlou@cec.eu.int, gordon.lennox@cec.eu.int, klaus.matzka@ilab24.com, "Jeff Pulver" , "Ed Guy" , , , , , herwart.wermescher@bearingpoint.com, Chris.Hessing@utah.edu, dreamguard@dreamguard.at, Jari Arkko , bb@siminn.is From: Michael Haberler Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-12347F98; boundary="=======302532F7=======" Subject: [Enum] ENUM & SIP applications tutorial - Sept 1 at RIPE-46 / Amsterdam Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======302532F7======= Content-Type: multipart/alternative; x-avg-checked=avg-ok-12347F98; boundary="=====================_42392717==.ALT" --=====================_42392717==.ALT Content-Type: text/plain; x-avg-checked=avg-ok-12347F98; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit For those considering or involved in ENUM trials and/or SIP service development: we will be holding a one-day tutorial on Monday Sept 1 at the RIPE-46 conference in Amsterdam - see below. Michael Haberler Jiri Kuthan Richard Stastny -- SIP Applications with ENUM This tuorial is designed to present the state of the art in Session Initiation Protocol application together with ENUM, a key enabler for PSTN-Internet interworking. We report experience from the Austrian ENUM field trial as well as large-scale application of the iptel.org SIP Express router for Voice over IP and Instant Messenging. The tutorial is geared towards persons involved in service rollouts as well as national ENUM trials. 90" SIP Introduction (Jiri Kuthan) Standardization status, Operational aspects - NAT, reliability, policy making PSTN Interworking - Network Asserted Identity, gateway operation Application building 60" ENUM Status (Richard Stastny) 30" Radius validation of ENUM delegations(Michael Haberler) 45" ENUM Usage with at43 and PBX usage as practical example - (Michael Haberler) 30" Remote Party ID and CLI - (Richard Stasty) 30" Trusted communication between SIP-servers (Jiri Kuthan) 30" SIM-card based authentication of SIP clients (Michael Haberler) About the speakers: Richard Stastny - (Project Manager, Telekom Austria/OEFEG) OeFEG is a subsidiary of Telekom Austria and providing Project Management and Consulting in Telecommunications. OeFEG is responsible also for the national specifications for digital switching and OAM/OSS/BSS systems. Richard has over 25 years of experience in computing, switching, signalling, numbering and networking. He was involved in the adaption of digital switching systems (DMS-100 and EWSD) for the Austrian market and also in the introduction of OAM and Billing Systems within Telekom Austria. Before he joined OEFEG in 1998 he was working with Schrack-Ericsson and Kapsch-Nortel. He is participating actively in various international standard bodies, e.g. ETSI SMG, TMN, SPAN and TIPHON, VISIONng, ITU-T SG2 and IETF. In the last years he was responsible in OeFEG for the convergence of NGN networks, the migration to IP based networks, VoIP and ENUM. In this role he was involved in the latest developments in ITU-T regarding the +878 country code for UPT and the recent ENUM related recommendations in ITU-T and ETSI . In ETSI he was rapporteur of ETSI TS 102 172 "Minimum Requirements for Interoperability of European ENUM trials". Richard is also the chair of the Austrian ENUM Trial Platform and taking an active role in the Austrian and VISIONng ENUM trials and the current co-operation with Free World Dialup. Jiri Kuthan - (GMD Fokus/iptel.org) is founder and technical leader of iptel.org. He has been responsible for engineering architecture of iptel ' s SIP services and underlying infrastructure. Prior to founding iptel.org, Jiri was working with GMD Fokus, and MCI Worldcom. Jiri has been actively participating in IETF standardization and serves on TPC of iptel workshop and International SIP. iptel.org is a SIP know-how and deployment company -- it created world ' s most unique open-source SIP server with premium service creation flexibility and performance. The server has been powering iptel.org ' s public services as well as services of iptel ' s customers for more than two years. iptel.org ' s provides consultancy to both operators and vendors in the SIP area. Michael Haberler - Internet Foundation Austria (IPA) Is chairman of the beneficial Internet Foundation Austria (IPA), the owner of the Austrian registry nic.at, and founder of the former EUnet Austria. --=====================_42392717==.ALT Content-Type: text/html; x-avg-checked=avg-ok-12347F98; charset=us-ascii Content-Transfer-Encoding: 8bit For those considering or involved in ENUM trials and/or SIP service development:

we will be holding a one-day tutorial on Monday Sept 1 at the RIPE-46 conference in Amsterdam - see below.

Michael Haberler
Jiri Kuthan
Richard Stastny

--


SIP Applications with ENUM

This tuorial is designed to present the state of the art in Session Initiation Protocol application together with ENUM, a key enabler for PSTN-Internet interworking. We report experience from the Austrian ENUM field trial as well as large-scale application of the iptel.org SIP Express router for Voice over IP and Instant Messenging. The tutorial is geared towards persons involved in service rollouts as well as national ENUM trials.

90"  SIP Introduction (Jiri Kuthan)
     Standardization status,
     Operational  aspects - NAT, reliability, policy making
     PSTN Interworking - Network Asserted Identity, gateway operation
     Application building
60" ENUM Status (Richard Stastny)
30" Radius validation of ENUM delegations(Michael Haberler)
45" ENUM  Usage with at43 and PBX usage as practical example - (Michael Haberler)
30" Remote Party ID and CLI - (Richard Stasty)
30" Trusted communication between SIP-servers (Jiri Kuthan)
30" SIM-card based authentication of SIP clients (Michael Haberler)


About the speakers:

Richard Stastny - (Project Manager, Telekom Austria/OEFEG)

OeFEG is a subsidiary of Telekom Austria and providing Project Management and Consulting in Telecommunications. OeFEG is responsible also for the national specifications for digital switching and OAM/OSS/BSS systems.

Richard has over 25 years of experience in computing, switching, signalling, numbering and networking. He was involved in the adaption of digital switching systems (DMS-100 and EWSD) for the Austrian market and also in the introduction of OAM and Billing Systems within Telekom Austria. Before he joined OEFEG in 1998 he was working with Schrack-Ericsson and Kapsch-Nortel.

He is participating actively in various international standard bodies, e.g. ETSI SMG, TMN, SPAN and TIPHON, VISIONng, ITU-T SG2 and IETF. In the last years he was responsible in OeFEG for the convergence of NGN networks, the migration to IP based networks, VoIP and ENUM. In this role he was involved in the latest developments in ITU-T regarding the +878 country code for UPT and the recent ENUM related recommendations in ITU-T and ETSI . In ETSI he was rapporteur of ETSI TS 102 172 "Minimum Requirements for Interoperability of European ENUM trials".

Richard is also the chair of the Austrian ENUM Trial Platform and taking an active role in the Austrian and VISIONng ENUM trials and the current co-operation with Free World Dialup.


Jiri Kuthan - (GMD Fokus/iptel.org)

is founder and technical leader of iptel.org. He has been responsible for engineering architecture of iptel ' s SIP services and underlying infrastructure. Prior to founding iptel.org, Jiri was working with GMD Fokus, and MCI Worldcom. Jiri has been actively participating in IETF standardization and serves on TPC of iptel workshop and International SIP.

iptel.org is a SIP know-how and deployment company -- it created world ' s most unique open-source SIP server with premium service creation flexibility and performance. The server has been powering iptel.org ' s public services as well as services of iptel ' s customers for more than two years. iptel.org ' s provides consultancy to both operators and vendors in the SIP area.


Michael Haberler - Internet Foundation Austria (IPA)

Is chairman of the beneficial Internet Foundation Austria (IPA), the owner of the Austrian registry nic.at, and founder of the former EUnet Austria.
--=====================_42392717==.ALT-- --=======302532F7=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 28 12:38:41 2003 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 MAA11815 for ; Mon, 28 Jul 2003 12:38:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0n-0005lx-O8 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 12:38:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SGcDWE022174 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 12:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0b-0005kn-Ds; Mon, 28 Jul 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0P-0005iw-3Q for enum@optimus.ietf.org; Mon, 28 Jul 2003 12:37:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11785 for ; Mon, 28 Jul 2003 12:37:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hB0N-0005Wr-00 for enum@ietf.org; Mon, 28 Jul 2003 12:37:47 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19hB0M-0005Wf-00 for enum@ietf.org; Mon, 28 Jul 2003 12:37:46 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h6SGaxc16990; Mon, 28 Jul 2003 16:36:59 GMT Message-Id: <5.2.0.9.2.20030728121845.039ece60@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Jul 2003 12:23:06 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Sabine Dolderer/Denic From: Richard Shockey Subject: Re: [Enum] CRISP Cc: enum@ietf.org, Jim.Reid@nominum.com, KMcCandless@verisign.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 11:11 AM 7/24/2003 +0200, Patrik F=E4ltstr=F6m wrote: >On torsdag, jul 24, 2003, at 09:31 Europe/Stockholm, Sabine Dolderer/Denic= =20 >wrote: > >>just for clarification. >> >>Which data you plan to publish in the Swedish enum trial via whois/crisp >> >>- the holder of the enum domain/e.164 number =3D registrant? > >No. I don't think so. The requirements coming out of the US ENUM forum do not suggest that CRISP= =20 would be used for number holder/registrant but only for .... >>- the maintainer of the nameserver to whom the enum domain is delegated? > >Yes. Precisely... >>and if the second case is true. Only the information for the primary dns >>(how do you identify them) or all nameservers of the delegation? > >I don't know yet. We are exactly at the point in the project where things= =20 >like this is discussed. We're not sure about that as well... In any event t has been discussed extensively in the US and the conclusion= =20 was that classic 43 WHOIS is unacceptable. All of this BTW is national trial specific there is no global requirement=20 here at all. >>And which information for all cases exactly (name, address, phone, fax, >>email, ...) > >I have no idea. I think the project will look at what is stored today in=20 >DNS for DNS operations, and start with that. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 28 12:38:43 2003 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 MAA11816 for ; Mon, 28 Jul 2003 12:38:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0n-0005lu-OE for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 12:38:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SGcDtV022173 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 12:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0b-0005kw-Vd; Mon, 28 Jul 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hB0V-0005kD-7x for enum@optimus.ietf.org; Mon, 28 Jul 2003 12:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11791 for ; Mon, 28 Jul 2003 12:37:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hB0Q-0005Wz-00 for enum@ietf.org; Mon, 28 Jul 2003 12:37:50 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19hB0Q-0005Wh-00 for enum@ietf.org; Mon, 28 Jul 2003 12:37:50 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h6SGaxc16995; Mon, 28 Jul 2003 16:37:00 GMT Message-Id: <5.2.0.9.2.20030728122352.03bc3008@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Jul 2003 12:33:00 -0400 To: Jim Reid , James Seng From: Richard Shockey Subject: Re: [Enum] CRISP Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Sabine Dolderer/Denic , enum@ietf.org, KMcCandless@verisign.com In-Reply-To: <98323.1059040513@shell.nominum.com> References: <3F1FA600.9070103@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At > James> What we do need is the WHOIS/IRIS info for the CC registry > James> which is=20 already published in RIPE-NCC. > >Who's "we"? > >Even without RIPE's whois server this information can be obtained, >albeit in a painful way. ITU can point you at the official ENUM >contact for a National Administration. That official will be able to >identify the technical contact for the Tier-1 registry. Or identify >someone who can do that. > >BTW, Patrik's recent remarks aside, nobody has yet come forward with >reasons or justifications for whois/crisp for ENUM. Well thats like asking why do we have whois at all? In order to preserve the security and stability of the Internet it is necessary to have authoritive directories of who is responsible for the proper functioning of name servers responsible for specific domains. That the requirement here. > And I've still to >see any data which shows how often existing whois data -- not >necessarily under e164.arpa! -- is accessed to solve operational >issues. I would really like this WG answer the question "do we have a >real need for whois/crisp/whatever?" before jumping headlong into a >whole bunch of nasty issues like data protection, privacy, protocol >holy wars and so on. Where are the Delegation Police and how much >reliance do they have on whois? Well again these issues are coming out of various national ENUM trial or operational requirements that are beginning to surface. We are trying to provide appropriate technical guidance to those trials and that is within our charter. Now some national ENUM adminstrations may require E.164 holder/registrant data but that is not our business. As of now I have seen none ... and its seems rational we have white page phone data available everywhere. Going to Andrew Newton's earlier post ..yes an applicability statement might be useful here but we seem to know why whois was useful in the first place. I personally want this work to go forward there is the larger issue of when the CRISP WG formally decides on the IRIS vs FIRS issue but I want it to be perfectly clear that I'm not neutral on that debate. I prefer IRIS to FIRS for any number of reasons you can view on that mail list. >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 28 14:39:38 2003 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 OAA15586 for ; Mon, 28 Jul 2003 14:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCtr-0002V7-OF for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 14:39:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SIdBoL009595 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 14:39:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCtg-0002UB-Jr; Mon, 28 Jul 2003 14:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCsl-0002S6-IW for enum@optimus.ietf.org; Mon, 28 Jul 2003 14:38:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15462 for ; Mon, 28 Jul 2003 14:37:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCsi-0006aK-00 for enum@ietf.org; Mon, 28 Jul 2003 14:38:00 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19hCsi-0006ZU-00 for enum@ietf.org; Mon, 28 Jul 2003 14:38:00 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 66388137F3A; Mon, 28 Jul 2003 11:37:29 -0700 (PDT) To: Richard Shockey Cc: James Seng , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Sabine Dolderer/Denic , enum@ietf.org, KMcCandless@verisign.com Subject: Re: [Enum] CRISP In-Reply-To: Message from Richard Shockey of "Mon, 28 Jul 2003 12:33:00 EDT." <5.2.0.9.2.20030728122352.03bc3008@shockey.us> Date: Mon, 28 Jul 2003 11:37:29 -0700 Message-ID: <98469.1059417449@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Richard" == Richard Shockey writes: >> BTW, Patrik's recent remarks aside, nobody has yet come forward >> with reasons or justifications for whois/crisp for ENUM. Richard> Well thats like asking why do we have whois at all? Exactly! Richard> In order to preserve the security and stability of the Richard> Internet it is necessary to have authoritive directories Richard> of who is responsible for the proper functioning of name Richard> servers responsible for specific domains. Indeed. But are we *sure* whois or crisp is the answer? Maybe it's enough for the registry to capture the customer data and make that available on a need-to-know basis, for instance if a delegation is lame? Even then, why should the registry care if my ENUM name servers are broken unless they have a contract with me to provide DNS service? Richard> That the requirement here. To some extent, I'm playing Devil's Advocate here. Personally I'm not convinced of the value of whois-like info. That's why it would be nice to see some hard data on its actual worth. I'm also wondering how much divergence there is between the DNS and whois "databases" as well as the amount of effort that will be needed to keep these synchronised. Do the benefits really justify the costs? And are we going down the whois/crisp path "because we've always done domain names this way"? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Mon Jul 28 15:46:30 2003 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 PAA18521 for ; Mon, 28 Jul 2003 15:46:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwF-0004vp-N8 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjhpZ018946 for enum-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvl-0004ix-HY; Mon, 28 Jul 2003 15:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvP-0004cF-Rp for enum@optimus.ietf.org; Mon, 28 Jul 2003 15:44:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18187 for ; Mon, 28 Jul 2003 15:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvO-000746-00 for enum@ietf.org; Mon, 28 Jul 2003 15:44:50 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19hDvN-00073x-00 for enum@ietf.org; Mon, 28 Jul 2003 15:44:49 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] CRISP MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 28 Jul 2003 21:48:55 +0200 Message-ID: <06CF906FE3998C4E944213062009F16223374C@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] CRISP Thread-Index: AcNVJ2RL2F79X/CSQ625XkFTqwNdcwAGKkti From: "Stastny Richard" To: "Richard Shockey" , "Jim Reid" , "James Seng" Cc: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Sabine Dolderer/Denic" , , Content-Transfer-Encoding: base64 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 UmljaGFyZCBTaG9ja2V5IHdyb3RlOg0KIA0KPldlbGwgYWdhaW4gdGhlc2UgaXNzdWVzIGFyZSBj b21pbmcgb3V0IG9mIHZhcmlvdXMgbmF0aW9uYWwgRU5VTSB0cmlhbCBvcg0KPm9wZXJhdGlvbmFs IHJlcXVpcmVtZW50cyB0aGF0IGFyZSBiZWdpbm5pbmcgdG8gc3VyZmFjZS4gV2UgYXJlIHRyeWlu ZyB0bw0KPnByb3ZpZGUgYXBwcm9wcmlhdGUgdGVjaG5pY2FsIGd1aWRhbmNlIHRvIHRob3NlIHRy aWFscyBhbmQgdGhhdCBpcyB3aXRoaW4NCj5vdXIgY2hhcnRlci4NCg0KPk5vdyBzb21lIG5hdGlv bmFsIEVOVU0gYWRtaW5zdHJhdGlvbnMgbWF5IHJlcXVpcmUgRS4xNjQgaG9sZGVyL3JlZ2lzdHJh bnQNCj5kYXRhIGJ1dCB0aGF0IGlzIG5vdCBvdXIgYnVzaW5lc3MuICBBcyBvZiBub3cgSSBoYXZl IHNlZW4gbm9uZSAuLi4gYW5kIGl0cw0KPnNlZW1zIHJhdGlvbmFsIHdlIGhhdmUgd2hpdGUgcGFn ZSBwaG9uZSBkYXRhIGF2YWlsYWJsZSBldmVyeXdoZXJlLg0KDQpFeGFjdGx5LCBpdCBpcyBub3Qg b3VyIGJ1c2luZXNzLiBJIGFsd2F5cyB0aG91Z2h0IHdlIGFyZSBkb2luZyBwcm90b2NvbHMgaGVy ZToNCiANCkkgd2FzIGhvbGRpbmcgYmFjayBoZXJlIGluIHRoaXMgZGljdXNzaW9uLCBidXQgaWYg SSBkZXNpZ24gYSBwcm90b2NvbCBvciBhIGRhdGFiYXNlDQpzeXN0ZW0gSSBkbyBOT1QgZGlzY3Vz cyB0aGUgZGF0YSB0byBiZSB0cmFuc2ZlcnJlZCBvciBzdG9yZWQsIGFuZCBldmVuIHdvcnNlLA0K aWYgaXQgaXMgcG9saXRjYWwgY29ycmVjdCB0byBzdG9yZSB0aGlzIGRhdGEgb3Igbm90Lg0KIA0K SSBtYXkgZGlzY3VzcyBhY2Nlc3MgcmlnaHQgYW5kIHNlY3VyaXR5IHRvIGRhdGEsIGJ1dCBpZiBz b21lb25lIGRlY2lkZXMgdG8gaGF2ZSB0aGUNCnJlZ2lzdHJhbnRzIGRhdGEgc3RvcmVkIChwdWJs aWMgb3Igbm90KSwgaGUgc2hvdWxkIGJlIGFibGUgdG8gZG8gc28uDQogDQpBcyBzdGF0ZWQgYWJv dmUsIHRoaXMgaXMgbm90IG91ciBidXNpbmVzcy4NCiANClJpY2hhcmQNCg== _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 29 10:37:03 2003 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 KAA24984 for ; Tue, 29 Jul 2003 10:37:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVah-0004ld-67 for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 10:36:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TEadxM018314 for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 10:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVa5-0004it-7z; Tue, 29 Jul 2003 10:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVZ6-0004h1-Qr for enum@optimus.ietf.org; Tue, 29 Jul 2003 10:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24895; Tue, 29 Jul 2003 10:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hVZ4-00066B-00; Tue, 29 Jul 2003 10:34:58 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 19hVZ3-000665-00; Tue, 29 Jul 2003 10:34:57 -0400 Received: from rshockeybox.neustar.biz (stsc650-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h6TEYOc19603; Tue, 29 Jul 2003 14:34:24 GMT Message-Id: <5.2.0.9.2.20030707103739.0321ce70@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 10:30:21 -0400 To: iesg-secretary@ietf.org From: Richard Shockey Cc: paf@cisco.com, mankin@psg.com, jon.peterson@neustar.biz, enum@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Request to Publish : draft-ietf-enum-h323-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a request for publication for one IETF ENUM WG working group document. WG last call on this document concluded on July 22 ,2003... The document listed below is being proposed for Standards Track RFC. Status- Proposed Standard This document is a ENUM Working Group product, which has been extensively discussed during 2003. Title : ENUM Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-ietf-enum-h323-01.txt Pages : 4 Date : 2003-6-27 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 29 21:19:51 2003 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 VAA18498 for ; Tue, 29 Jul 2003 21:19:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfck-0001T3-9f for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 21:19:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U1JQYA005597 for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 21:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfcL-0001Rl-4B; Tue, 29 Jul 2003 21:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfbV-0001RB-8z for enum@optimus.ietf.org; Tue, 29 Jul 2003 21:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18473 for ; Tue, 29 Jul 2003 21:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfbS-0003oL-00 for enum@ietf.org; Tue, 29 Jul 2003 21:18:06 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19hfbS-0003oI-00 for enum@ietf.org; Tue, 29 Jul 2003 21:18:06 -0400 Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6U1LWa20966; Tue, 29 Jul 2003 18:21:32 -0700 Message-Id: <5.2.0.9.2.20030729210710.025bb6a0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 21:13:05 -0400 To: enum@ietf.org From: Richard Shockey Cc: enum-trials@ripe.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Author Inquiry on ENUM trial Status...etc Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Yours truly has been asked by the Cisco Internet Protocol Journal to write a article on the current status of ENUM including updates on various national ENUM trials. I would appreciate any updates on URL's etc sent to me privately. In addition anyone involved in national enum trials willing to be interviewed privately via email would be appreciated as well. Thank you for your consideration...we will now return you to our regularly scheduled programming. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From exim@www1.ietf.org Tue Jul 29 23:08:39 2003 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 XAA20798 for ; Tue, 29 Jul 2003 23:08:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhK4-000506-Al for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 23:08:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U38GBR019220 for enum-archive@odin.ietf.org; Tue, 29 Jul 2003 23:08:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhJo-0004y1-V0; Tue, 29 Jul 2003 23:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhJG-0004nm-Pk for enum@optimus.ietf.org; Tue, 29 Jul 2003 23:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20744 for ; Tue, 29 Jul 2003 23:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hhJC-0004Ny-00 for enum@ietf.org; Tue, 29 Jul 2003 23:07:22 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19hhJB-0004Nj-00 for enum@ietf.org; Tue, 29 Jul 2003 23:07:21 -0400 Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h6U3Aua25285 for ; Tue, 29 Jul 2003 20:10:56 -0700 Message-Id: <5.2.0.9.2.20030729230121.027a3b28@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 23:01:30 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-ietf-enum-privacy-security-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-enum-privacy-security-01.txt >Date: Tue, 29 Jul 2003 12:14:39 -0400 >Sender: owner-ietf-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Privacy and Security Considerations in ENUM > Author(s) : R. Shockey et al. > Filename : draft-ietf-enum-privacy-security-01.txt > Pages : 17 > Date : 2003-7-29 > >Many individuals and groups have expressed concerns about the >privacy and security of personal information to be established in >implementations of RFC 2916. This document discusses some of the >technical as well as security and privacy considerations national >implementations of ENUM should consider. >This is a work in progress. Input from security and privacy >experts is welcome. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-privacy-security-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-enum-privacy-security-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-enum-privacy-security-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-29122649.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-enum-privacy-security-01.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum