From hank at mail.iucc.ac.il Mon May 2 08:57:41 2005 From: hank at mail.iucc.ac.il (Hank Nussbacher) Date: Mon, 02 May 2005 09:57:41 +0300 Subject: [address-policy-wg] New Draft Document: RIPE Whois Registration in 2005: What should be in Whois and Why? In-Reply-To: <4270F86A.2000107@ripe.net> Message-ID: <5.1.0.14.2.20050502095223.00ab1460@mail.iucc.ac.il> At 04:51 PM 28-04-05 +0200, leo vegoda wrote: Item 10 of this draft discusses the "country" tag. The Israeli exchange (IIX) filters based on country tag: http://www.isoc.org.il/fr_reload.html?iix/2x_bylaws.4 Since the exchange is designated to only route intra-Israel traffic, the country tag on inetnum entries is the easiest way to filter traffic. Regards, Hank >Dear Colleagues, > >At RIPE 49, Eva Ericsson Rabete (TeliaSonera) made a presentation to the >Address Policy Working Group in which she asked some questions about the >state of the RIPE Whois Database. Following the discussion at the meeting, >Eva was asked to take the discussion onto this list (Action Point 49.4). > >A draft document discussing the uses of the RIPE Whois Database, and >detailing questions to consider, has been published in the "Latest Draft >Documents" section of the RIPE Document Store. > >The purpose of this draft document is to encourage discussion about what >elements should be in the Whois Database and why they should be there. > >This draft document is available at: >http://www.ripe.net/ripe/draft-documents/whois2005.html > >Regards, > >-- >leo vegoda >Registration Services Manager >RIPE NCC > >+++++++++++++++++++++++++++++++++++++++++++ >This Mail Was Scanned By Mail-seCure System >at the Tel-Aviv University CC. From hpholen at tiscali.no Wed May 4 19:11:13 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 04 May 2005 19:11:13 +0200 Subject: [address-policy-wg] Revised Agenda v2 for Address Policy WG @ RIPE 50 Thursday 5th May Message-ID: <42790231.5000203@tiscali.no> Time: 1400- 15:30 Date: Tursday May 5th Place: Main room, RIPE 50 A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP --- PDP last call posted to ripe-list with closing date May 10th. C. Policy proposal: #alpha: TLD Anycast Allocation Policy Discussion phase until: May 6th D. Policy proposal: #beta: IPv4-HD-Ratio Discussion phase until: April 4th E. Policy proposal: #gamma: IPv6 remove 200 customer requirement Discussion phase until May: 9th F. Policy Proposal: #epsilon: Removal of Africa Special Policy Discussion phase until May: 1st G. Policy Proposal: #zeta: Adding Regional Boundaries to Policy Documents Discussion phase until May: 1st H. Discussion: (IPv6) HD ratio consequences (Geoff Huston: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf There is also a related agenda item in the IPv6 WG on friday: http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2005/msg00042.html " D. Revisiting the /48 recommendation (Thomas Narten) Discussion, read rfc3177 as preparation ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt" J. Report from the Address Council - Hans Petter Holen K. Any other Business From hpholen at tiscali.no Thu May 5 12:16:36 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 05 May 2005 12:16:36 +0200 Subject: [address-policy-wg] Revised Agenda v3 for Address Policy WG @ RIPE 50 Thursday 5th May In-Reply-To: <42790231.5000203@tiscali.no> References: <42790231.5000203@tiscali.no> Message-ID: <4279F284.4030000@tiscali.no> Time: 1400- 15:30 Date: Tursday May 5th Place: Main room, RIPE 50 A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP --- PDP last call posted to ripe-list with closing date May 10th. C. Report from the Address Council - Hans Petter Holen D. Policy proposal: #alpha: TLD Anycast Allocation Policy Discussion phase until: May 6th E. Policy proposal: #beta: IPv4-HD-Ratio Discussion phase until: April 4th F. Policy proposal: #gamma: IPv6 remove 200 customer requirement Discussion phase until May: 9th G. IPv6 Global Poliicy status - Ray Plzak, ARIN H. Policy Proposal: #epsilon: Removal of Africa Special Policy Discussion phase until May: 1st I. Policy Proposal: #zeta: Adding Regional Boundaries to Policy Documents Discussion phase until May: 1st J. Discussion: (IPv6) HD ratio consequences (Geoff Huston: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf There is also a related agenda item in the IPv6 WG on friday: http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2005/msg00042.html " D. Revisiting the /48 recommendation (Thomas Narten) Discussion, read rfc3177 as preparation ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt" K. Any other Business From freeram at free.fr Fri May 6 14:44:15 2005 From: freeram at free.fr (freeram) Date: Fri, 6 May 2005 14:44:15 +0200 Subject: [address-policy-wg] infected e mails Message-ID: <001001c55239$6265f630$0100a8c0@FAMILIALHIDHQ> I receive infected e mails of these addresses is it possible to ascend has the author of its mails: or have I to address to send complaints thank you of well will to reply me Alain Bruneteau ---------------------------------------------------------------------------------------------------- 62.48.149.242 Return-Path: Delivered-To: online.fr-freeram at free.fr Received: (qmail 9962 invoked from network); 6 May 2005 10:41:25 -0000 Received: from adsl-62-48-149-242.ptprime.net (HELO tetfob.pt) (62.48.149.242) by mrelay2-2.free.fr with SMTP; 6 May 2005 10:41:25 -0000 From: info at sivaonline.pt To: Recipient at free.fr Date: Fri, 06 May 2005 09:52:45 UTC Subject: [avast! - INFECTED] Your email was blocked Importance: Normal X-Priority: 3 (Normal) Message-ID: <56cd.70f8e0dab9d7ee0 at sivaonline.pt> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===79bce1635598.2ceab3bf964" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-4, 06/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \error-mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted ------------------------------------------------------------------------------------------------- 82.64.236.212 X-x: TimeOut+OK 73580 octets Return-Path: Delivered-To: online.fr-freeram at free.fr Received: (qmail 12725 invoked from network); 5 May 2005 06:17:15 -0000 Received: from lns-th2-15-poi-82-64-236-212.adsl.proxad.net (HELO butqay.fr) (82.64.236.212) by mrelay3-2.free.fr with SMTP; 5 May 2005 06:17:15 -0000 From: hostmaster at yahoo.fr To: mailhost at free.fr Date: Thu, 05 May 2005 06:09:40 UTC Subject: [avast! - INFECTED] mailing error Importance: Normal X-Priority: 3 (Normal) Message-ID: <74d8c001e683ef48 at yahoo.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6653bc9b707531bc.8" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-3, 04/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted --------------------------------------------------------------------------------------------------- 82-64-238-162 Return-Path: Delivered-To: online.fr-freeram at free.fr Received: (qmail 17762 invoked from network); 4 May 2005 05:53:29 -0000 Received: from lns-th2-15-poi-82-64-238-162.adsl.proxad.net (HELO hnmuwxt.fr) (82.64.238.162) by mrelay1-2.free.fr with SMTP; 4 May 2005 05:53:29 -0000 From: Admin at ac-corse.fr To: fe2e2ec0 at free.fr Date: Wed, 04 May 2005 05:45:09 GMT Subject: [avast! - INFECTED] mailing error Importance: Normal X-Priority: 3 (Normal) X-MSMail-Priority: Normal Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=====8389c8.dea2bff67" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-2, 04/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \error-mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted ---------------------------------------------------------------------------------------------------- 82.64.226.163 Return-Path: Delivered-To: online.fr-freeram at free.fr Received: (qmail 7819 invoked from network); 4 May 2005 23:00:38 -0000 Received: from lns-th2-15-poi-82-64-226-163.adsl.proxad.net (HELO osymwmxh.fr) (82.64.226.163) by mrelay2-1.free.fr with SMTP; 4 May 2005 23:00:38 -0000 From: service at ac-reims.fr To: oel at free.fr Date: Wed, 04 May 2005 23:00:06 GMT Subject: FwD: Registration Confirmation Importance: Normal X-Priority: 3 (Normal) X-MSMail-Priority: Normal Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==eb445d.b2cfb65" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncc at ripe.net Tue May 10 11:40:11 2005 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 10 May 2005 11:40:11 +0200 Subject: [address-policy-wg] Call for Comments on Revised ICANN Strategic Plan Message-ID: <5.2.1.1.2.20050510113832.060ecf38@mailhost.ripe.net> Dear Colleagues, The ICANN Strategic Plan has been revised. The comment period will be open until 13 May 2005 at 23:59 UTC. The revised Strategic Plan is available as a draft for public comment at: http://www.icann.org/strategic-plan/strategic-plan-v7_3.pdf We encourage you to review the ICANN Strategic Plan document and send any comments you have to: . Regards, Axel Pawlik Managing Director RIPE NCC From ncc at ripe.net Tue May 10 14:19:49 2005 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 10 May 2005 14:19:49 +0200 Subject: [address-policy-wg] Correction: Call for Comments on Revised ICANN Strategic Plan Message-ID: <5.2.1.1.2.20050510141839.01b1d850@mailhost.ripe.net> Dear Colleagues, Some of you may have noticed two URLs in our last announcement. The correct URL is: http://www.icann.org/strategic-plan/strategic-plan-v7_3.pdf Apologies for the confusion. Regards, Axel Pawlik Managing Director RIPE NCC From president at ukraine.su Thu May 12 13:39:25 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 12 May 2005 15:39:25 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information Message-ID: <200505121539.25776.president@ukraine.su> Hi! I have very strange situation. One company I support, an ISP, wants to become a LIR. But they do not want to put information about their clients' assignments into the RIPE DB, because of there is a possibility to steal clients (most of them - major clients) using RIPE DB, and they says that there already was some incidents. Really, you can see RIPE DB for assignments of LIR to have its client list with name of organisation, size (larger client have larger assignment), address, phone, fax, email, and even administrative and technical contact persons. Only you need to do - is to send (or even talk with) better offer addressing it to certain people... What do you think about it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From elmi at 4ever.de Thu May 12 13:56:57 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 12 May 2005 13:56:57 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121539.25776.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> Message-ID: <20050512115656.GR80299@new.detebe.org> president at ukraine.su (Max Tulyev) wrote: > Really, you can see RIPE DB for assignments of LIR to have its client list > with name of organisation, size (larger client have larger assignment), > address, phone, fax, email, and even administrative and technical contact > persons. Only you need to do - is to send (or even talk with) better offer > addressing it to certain people... > > What do you think about it? If you can only keep your clients through hiding any information about the connection, you have entirely different problems. Apart from that: The data of every assignment is in the RIPE database so that the actual user can held accountable for what they are doing. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From slz at baycix.de Thu May 12 14:05:05 2005 From: slz at baycix.de (Sascha Lenz) Date: Thu, 12 May 2005 14:05:05 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121539.25776.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> Message-ID: <42834671.4080404@baycix.de> Hi, Max Tulyev wrote: > Hi! > > I have very strange situation. > > One company I support, an ISP, wants to become a LIR. But they do not want to > put information about their clients' assignments into the RIPE DB, because of > there is a possibility to steal clients (most of them - major clients) using > RIPE DB, and they says that there already was some incidents. > > Really, you can see RIPE DB for assignments of LIR to have its client list > with name of organisation, size (larger client have larger assignment), > address, phone, fax, email, and even administrative and technical contact > persons. Only you need to do - is to send (or even talk with) better offer > addressing it to certain people... > > What do you think about it? > ...that this ISP just should not become a LIR if it doesn't feel like it can fulfil the requirements, like doing Assignments by the book? Actually, i think the ISP got worse problems if they need to hide their customers - most are proud of their more imporatant customers and mention them in big letters on their references webpages to show off. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From wilfried.woeber at univie.ac.at Thu May 12 13:54:37 2005 From: wilfried.woeber at univie.ac.at (woeber) Date: Thu, 12 May 2005 13:54:37 +0200 (MSZ) Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121539.25776.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> Message-ID: On Thu, 12 May 2005, Max Tulyev wrote: > What do you think about it? That as of today this is part of the set of rules for the game. And it is the same set of rules for everybody. Wilfried. From amar at telia.net Thu May 12 14:19:17 2005 From: amar at telia.net (amar andersson) Date: Thu, 12 May 2005 14:19:17 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050512115656.GR80299@new.detebe.org> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> Message-ID: <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> Quoting "Elmar K. Bins" : > If you can only keep your clients through hiding any information about > the connection, you have entirely different problems. Second that. That also gives Your client equal chance to steal customers from other opponents. -- amar From president at ukraine.su Thu May 12 14:28:51 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 12 May 2005 16:28:51 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> Message-ID: <200505121628.52041.president@ukraine.su> ? ????????? ?? ?????? 12 ??????? 2005 16:19 amar andersson ???????(a): > Quoting "Elmar K. Bins" : > > If you can only keep your clients through hiding any information about > > the connection, you have entirely different problems. > > Second that. > > That also gives Your client equal chance to steal customers from > other opponents. Please show me the Russian ISP showing their clients in RIPE DB ;) Most of them don't, as I can see. Most of major clients really are friends and don't change connection to anyone else. But some is just clients just using service - and will switch to others if there will be an [financial] reason. Having addressing database (with contact person, especially technical) there is easy to do this. So it seems to be good for you to share commertial information of ISP, and it should not be secret. Escalating the situation: will we need the connection-price: field in database? Why? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From elmi at 4ever.de Thu May 12 14:55:10 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 12 May 2005 14:55:10 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121628.52041.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> <200505121628.52041.president@ukraine.su> Message-ID: <20050512125510.GW80299@new.detebe.org> Hi Max, president at ukraine.su (Max Tulyev) wrote: > Most of major clients really are friends and don't change connection to anyone > else. But some is just clients just using service - and will switch to others > if there will be an [financial] reason. Having addressing database (with > contact person, especially technical) there is easy to do this. Well, if you have like, say, dialup customers, you may easily set aside a dialup-pool, enter this - registered to yourself (the ISP) - into the RIPE DB, and everything's fine. (Dynamic-IP) Dialup access has always been done with pools; the documentation necessity begins with statically-assigned adresses or networks. > So it seems to be good for you to share commertial information of ISP, and it > should not be secret. Escalating the situation: will we need the > connection-price: field in database? Why? I do not know how it is in Russia currently, but in Germany, the cost of an Internet connection is not only experienced through the retail price, but through other factors (services given, support, uptime, quality) as well. If you are on a bargaining market, you might stick to dialup/dynamic access and go the "best practice" I described above. If you want to deliver quality Internet, this quality thing does not only go towards your customer, it has to be brought towards the Internet (here: The RIPE community), too. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From sabt at sabt.net Thu May 12 15:00:24 2005 From: sabt at sabt.net (Sebastian Abt) Date: Thu, 12 May 2005 15:00:24 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121628.52041.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> <200505121628.52041.president@ukraine.su> Message-ID: <20050512130023.GC605@shiva.sabt.net> * Max Tulyev wrote: > Most of major clients really are friends and don't change connection > to anyone else. But some is just clients just using service - and will > switch to others if there will be an [financial] reason. Having Welcome to free market economy. > addressing database (with contact person, especially technical) there > is easy to do this. If your clients are satisfied they won't change their provider. If not they will change anyway, regardles of being listed in RIPE DB or not. So what's the problem at all? --sebastian -- SABT-RIPE PGPKEY-D008DA9C From president at ukraine.su Thu May 12 15:03:35 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 12 May 2005 17:03:35 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050512125510.GW80299@new.detebe.org> References: <200505121539.25776.president@ukraine.su> <200505121628.52041.president@ukraine.su> <20050512125510.GW80299@new.detebe.org> Message-ID: <200505121703.36075.president@ukraine.su> ? ????????? ?? ?????? 12 ??????? 2005 16:55 Elmar K. Bins ???????(a): > Well, if you have like, say, dialup customers, you may easily set aside > a dialup-pool, enter this - registered to yourself (the ISP) - into the > RIPE DB, and everything's fine. Yes, but it is good for the large group of small customers. But major customers have to have (at least officially must) their assignment into the RIPE DB. > I do not know how it is in Russia currently, but in Germany, the cost of > an Internet connection is not only experienced through the retail price, > but through other factors (services given, support, uptime, quality) as > well. If you are on a bargaining market, you might stick to dialup/dynamic > access and go the "best practice" I described above. If you want to deliver > quality Internet, this quality thing does not only go towards your > customer, it has to be brought towards the Internet (here: The RIPE > community), too. Quality can't be meansured and compared, so everybody says they have the best ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Thu May 12 15:11:21 2005 From: president at ukraine.su (Max Tulyev) Date: Thu, 12 May 2005 17:11:21 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050512130023.GC605@shiva.sabt.net> References: <200505121539.25776.president@ukraine.su> <200505121628.52041.president@ukraine.su> <20050512130023.GC605@shiva.sabt.net> Message-ID: <200505121711.21015.president@ukraine.su> ? ????????? ?? ?????? 12 ??????? 2005 17:00 Sebastian Abt ???????(a): > Welcome to free market economy. ;-))))) > > addressing database (with contact person, especially technical) there > > is easy to do this. > If your clients are satisfied they won't change their provider. If not > they will change anyway, regardles of being listed in RIPE DB or not. > So what's the problem at all? If my satisfied client will receive a tons of offers from other peoples just because of I show him in open database - it is really good??? Is it really good for me to look up the database and send that offers to others? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From sabri at cluecentral.net Thu May 12 14:36:15 2005 From: sabri at cluecentral.net (Sabri Berisha) Date: Thu, 12 May 2005 14:36:15 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121628.52041.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> <200505121628.52041.president@ukraine.su> Message-ID: <20050512123615.GA69925@cluecentral.net> On Thu, May 12, 2005 at 04:28:51PM +0400, Max Tulyev wrote: Hello Max, > connection-price: field in database? Why? If you would like to advertise your pricing in the RIPE database, you can always use the remarks: field.. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: sabri at cluecentral.net | cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/ From marcoh at marcoh.net Thu May 12 17:22:42 2005 From: marcoh at marcoh.net (MarcoH) Date: Thu, 12 May 2005 17:22:42 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050512125510.GW80299@new.detebe.org> References: <200505121539.25776.president@ukraine.su> <20050512115656.GR80299@new.detebe.org> <20050512141917.1st4qmtdwg8044gc@webmail.telia.net> <200505121628.52041.president@ukraine.su> <20050512125510.GW80299@new.detebe.org> Message-ID: <20050512152242.GA14063@marcoh.net> On Thu, May 12, 2005 at 02:55:10PM +0200, Elmar K. Bins wrote: > Well, if you have like, say, dialup customers, you may easily set aside > a dialup-pool, enter this - registered to yourself (the ISP) - into the > RIPE DB, and everything's fine. > > (Dynamic-IP) Dialup access has always been done with pools; the documentation > necessity begins with statically-assigned adresses or networks. That's more-or-less what we do, the large part of our customers are put in larger assignments which we hold full responsibillity for. Even on the business side although we note the name or a short form of it, we maintain responsible for the block and what they do with it, so unless the customer asks for it and has good reasons, we refer to our own admin-c and tech-c role objects. It's part of our service and I'm pretty interested in any misbehaviour of them, I don't want the customer to use it's own role to advertise his own address as abuse contact. Further, I wonder how many people are actually using the ripe-db for these kind of purposes (stealing customers as you call it), as there are other ways to find out like traceroute, domain registrations vs (secondary) nameservers or even a lookup of the in-addr.arpa zones. The risk is minimal as I see it and it's the rule. So as other people pointed out, if we everybody sticks to the procedure, we are all equal. MarcoH (on a sidenode, I'm referring to PA space here) From abramov at demos.net Fri May 13 08:06:10 2005 From: abramov at demos.net (Gennady Abramov) Date: Fri, 13 May 2005 10:06:10 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121711.21015.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <200505121628.52041.president@ukraine.su> <20050512130023.GC605@shiva.sabt.net> <200505121711.21015.president@ukraine.su> Message-ID: <20050513100610.15fae76c@abramov.demos.ru> On Thu, 12 May 2005 17:11:21 +0400 Max Tulyev wrote: > If my satisfied client will receive a tons of offers from other peoples just > because of I show him in open database - it is really good??? > > Is it really good for me to look up the database and send that offers to > others? I don't think that it's good for you to be a spammer :)) But, if you wish to send UCE to "target auditory", you can also find this "target auditory" from many over sources then RIPE DB.:) If your customer exists in RIPE DB, or if it has meaningfull PTR records on used addresses,it isn't gives someone advantage in stealing this customer from you. -- Gennady Abramov, CCNA, CCNP; Demos-Internet NOC abramov at demos.net, AGV77-RIPE From ncc at ripe.net Fri May 13 14:15:59 2005 From: ncc at ripe.net (Axel Pawlik) Date: Fri, 13 May 2005 14:15:59 +0200 Subject: [address-policy-wg] WGIG Questionnaire & Forum on Internet Governance Message-ID: <5.2.1.1.2.20050513141258.01b0d378@mailhost.ripe.net> Dear Colleagues, This is an invitation and an opportunity to provide input directly into the current discussions on Internet Governance. The UN's Working Group on Internet Governance (WGIG) is conducting a survey to ask stakeholders for their thoughts on current Internet Governance arrangements. The questionnaire is available on the WGIG website at: http://www.wgig.org/docs/Questionnaire.09.05.05.pdf An online discussion forum has also been established. Instructions on how to access the forum and complete the questionnaire can be found at: http://www.wgig.org/Plone-instructions.html I would like to encourage you to take a few minutes to respond to this survey. As a stakeholder in Internet governance, and in IP address management in particular, your input is important and will be valued by the WGIG. Regards, Axel Pawlik Managing Director RIPE NCC From dbell at redwingsat.com Mon May 16 11:17:06 2005 From: dbell at redwingsat.com (David Bell) Date: Mon, 16 May 2005 10:17:06 +0100 Subject: [address-policy-wg] Allocation transfer Message-ID: <07007503A38D6A47B4862B39E65E57EDCBAC4B@intranet.redwingsat.com> Hi all, uk.redwing is a small LIR, providing internet via satellite. We are in the process of hosting a new satellite platform, on behalf of another organisation, that is projecting a requirement for a /19 in the next 12 months. This partner is not currently an LIR, but is considering it as a future option. What I am trying to determine is if uk.redwing applies for this /19 address block, and assigns it as PA space, will it be possible in the future for us to hand it over to our partner, if/when they become an LIR themselves. Perhaps this is a case where PI addresses would be suitable, but I see warnings everywhere I look regarding the use of PI space. My apologies if this is not the correct place to post this question, please let me know the best place to go if I'm on the wrong list. Thanks very much, Dave Bell Redwing Satellite Solutions Ltd. From president at ukraine.su Mon May 16 14:17:44 2005 From: president at ukraine.su (Max Tulyev) Date: Mon, 16 May 2005 16:17:44 +0400 Subject: [address-policy-wg] Allocation transfer In-Reply-To: <07007503A38D6A47B4862B39E65E57EDCBAC4B@intranet.redwingsat.com> References: <07007503A38D6A47B4862B39E65E57EDCBAC4B@intranet.redwingsat.com> Message-ID: <200505161617.44516.president@ukraine.su> Hi Dave! PI is really usable on the practic! There is no problem with many ones I registered for my clients ;) But I think your customers wants /19 is not for themselves exactly, but for their clients. Current policy restricts giving subnets greater than /29 to clients without registering it into RIPE DB (assigning own networks for them) with end user's information. So if do things right way, they need to become LIR immediately to assign networks to their users. Remember, LIR will got ALLOCATED (not ASSIGNED) /19. Formally, there is not them space, but reserved for their clients. So them really need own LIR right now, and may look up for somebody (may be me? - hehe ;) ) can outsource LIR services if it is too expensieve for them now. If they are really end-users with a requirement of /19, you can ever assign them /19 or register /19 PI. PI is better because of there is no yearly payments for network ;) Ofcourse, there is a way when you will directly assign address space for their customers, but it is a wrong way because after a time you completly shouldn't divide it onto two independent LIRs without full renumbering. Other ways like got an PI /19 and giving space to users without any registering I do not say, because you are in UK, not in RU ;-) > uk.redwing is a small LIR, providing internet via satellite. We are in the > process of hosting a new satellite platform, on behalf of another > organisation, that is projecting a requirement for a /19 in the next 12 > months. This partner is not currently an LIR, but is considering it as a > future option. > > What I am trying to determine is if uk.redwing applies for this /19 address > block, and assigns it as PA space, will it be possible in the future for us > to hand it over to our partner, if/when they become an LIR themselves. > Perhaps this is a case where PI addresses would be suitable, but I see > warnings everywhere I look regarding the use of PI space. > > My apologies if this is not the correct place to post this question, please > let me know the best place to go if I'm on the wrong list. > > > > Thanks very much, > > > Dave Bell > Redwing Satellite Solutions Ltd. -- ? ?????????, ?????? ?????? (MT6561-RIPE, 2:463/253 at FIDO) From marcus.gerdon at mainz-kom.de Mon May 16 15:35:12 2005 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Mon, 16 May 2005 15:35:12 +0200 Subject: [address-policy-wg] Allocation transfer References: <07007503A38D6A47B4862B39E65E57EDCBAC4B@intranet.redwingsat.com> Message-ID: <004201c55a1c$16222dd0$828e8bd5@asgaard> Hi Dave, there are two ways possibe to accomplish this as I'd take the policies. First would be as your question was: You could apply for a (additional) /19 allocation and assign it to your customer. Later on when they've become a LIR themselves you can contact NCC for transfer of this allocation to your customers LIR. I've not found any detailed information ad hoc but in document RIPE-301 (intended for mergers, take-overs and so on) is the possibility of transferring a resource mentioned without any direct relationship to closure or merger of the originating LIR. Second is what I think would be the most 'correct' way to do this: Some time ago (if my memory's right it's about 1 1/2 years ago) RIPE added the option for assignments as 'SUB-ALLOCATION' which on a quick glance is exactly what you plan to do: hand a larger address range to another network operator for assignment to customers without him being a LIR himself. Just check document RIPE-324 for this. Just check the documents (especially 324) and maybe contact lir-help for their opinion on this. And please keep your hands off doing PI for this. Although /19 PI wouldn't make any difference to /19 PA within the routing tables, your customer won't be able to do any sub-assignments with registering them in the RIPE database using PI. I wouldn't want to get SPAM notifications for a /19 bunch of addresses only because I'm not able to add distinguished contacts for address ranges handed to customers. regards, Marcus --------------------------------------------------------- mainzkom Telekommunikation GmbH Ein Unternehmen der Tropolys-Gruppe Network Engineering and Administration mainzkom / maineotk / pulsaar Tel: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany --------------------------------------------------------- AS15837 | MG3031-RIPE --------------------------------------------------------- ----- Original Message ----- From: "David Bell" To: Sent: Monday, May 16, 2005 11:17 AM Subject: [address-policy-wg] Allocation transfer > Hi all, > > uk.redwing is a small LIR, providing internet via satellite. We are in the > process of hosting a new satellite platform, on behalf of another > organisation, that is projecting a requirement for a /19 in the next 12 > months. This partner is not currently an LIR, but is considering it as a > future option. > > What I am trying to determine is if uk.redwing applies for this /19 address > block, and assigns it as PA space, will it be possible in the future for us > to hand it over to our partner, if/when they become an LIR themselves. > Perhaps this is a case where PI addresses would be suitable, but I see > warnings everywhere I look regarding the use of PI space. > > My apologies if this is not the correct place to post this question, please > let me know the best place to go if I'm on the wrong list. > > > > Thanks very much, > > > Dave Bell > Redwing Satellite Solutions Ltd. > > From gert at space.net Mon May 16 21:48:45 2005 From: gert at space.net (Gert Doering) Date: Mon, 16 May 2005 21:48:45 +0200 Subject: [address-policy-wg] Allocation transfer In-Reply-To: <004201c55a1c$16222dd0$828e8bd5@asgaard> References: <07007503A38D6A47B4862B39E65E57EDCBAC4B@intranet.redwingsat.com> <004201c55a1c$16222dd0$828e8bd5@asgaard> Message-ID: <20050516194845.GU84850@Space.Net> Hi, On Mon, May 16, 2005 at 03:35:12PM +0200, Marcus Gerdon wrote: > You could apply for a (additional) /19 allocation and assign it to your > customer. > Later on when they've become a LIR themselves you can contact NCC for > transfer of this allocation to your customers LIR. I've not found any > detailed > information ad hoc but in document RIPE-301 (intended for mergers, > take-overs > and so on) is the possibility of transferring a resource mentioned without > any > direct relationship to closure or merger of the originating LIR. Moving LIR allocations to another LIR is definitely possible, if both LIRs agree that they want this. > Second is what I think would be the most 'correct' way to do this: > > Some time ago (if my memory's right it's about 1 1/2 years ago) RIPE added > the > option for assignments as 'SUB-ALLOCATION' which on a quick glance is > exactly what you plan to do: hand a larger address range to another network > operator > for assignment to customers without him being a LIR himself. Just check > document > RIPE-324 for this. Yes, that could be a viable approach. Start with a suballocation (that's conveniently located near the border of your allocation) and eventually move over the /19. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From groeskens at bluewin.ch Fri May 13 21:18:24 2005 From: groeskens at bluewin.ch (Guido Roeskens) Date: Fri, 13 May 2005 21:18:24 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505121711.21015.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <200505121628.52041.president@ukraine.su> <20050512130023.GC605@shiva.sabt.net> <200505121711.21015.president@ukraine.su> Message-ID: <4284FD80.1050202@bluewin.ch> Max Tulyev wrote: > ? ????????? ?? ?????? 12 ??????? 2005 17:00 Sebastian Abt ???????(a): > >>Welcome to free market economy. > > > ;-))))) > > >>>addressing database (with contact person, especially technical) there >>>is easy to do this. In most countries technical contacts don't decide which ISP to buy connectivity from... (Technical people look for the best, while "management" looks for the price... Technical people have to proof why solution A is better that B and sometimes are ignored anyway) >> >>If your clients are satisfied they won't change their provider. If not >>they will change anyway, regardles of being listed in RIPE DB or not. >>So what's the problem at all? > Besides, there are other ways to find the info you want: - dig (nslookup) www.bibgcompany.su -> IP address whois IP address -> you know which ISP's customer the company is - dig (nslookup -type=SOA) bibgcompany.su (SOA) -> E-Mail address of responisble for dns - send mail to info at bigcompany.su ... - Meybe use a phone book and call in? ..... > > If my satisfied client will receive a tons of offers from other peoples just > because of I show him in open database - it is really good??? In western (european?) countries there are trade laws which don't allow address harvesting (especially whois entries and other public data), placing unwanted offers, etc. You always can try to sell your offers however and it may be difficult to proof that others misued whaterver data (e.g. whois records) > > Is it really good for me to look up the database and send that offers to > others? > I can't see any advantage not place the customers in the whois DB, since there are other ways to find contact to them. Maybe the customers may not wan't to published there for whaterver reasons this might be. Guido From president at ukraine.su Tue May 17 10:50:49 2005 From: president at ukraine.su (Max Tulyev) Date: Tue, 17 May 2005 12:50:49 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <4284FD80.1050202@bluewin.ch> References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <4284FD80.1050202@bluewin.ch> Message-ID: <200505171250.49445.president@ukraine.su> Hello! > In most countries technical contacts don't decide which ISP to > buy connectivity from... But technical peoples are that neck directing the head ;-) > Besides, there are other ways to find the info you want: > - dig (nslookup) www.bibgcompany.su -> IP address > whois IP address -> you know which ISP's customer the company is > - dig (nslookup -type=SOA) bibgcompany.su (SOA) -> E-Mail address > of responisble for dns > - send mail to info at bigcompany.su ... > - Meybe use a phone book and call in? Ofcource yes. But RIPE DB is amazing tool if an attack directed againist certain ISP. > In western (european?) countries there are trade laws which don't allow > address harvesting (especially whois entries and other public data), > placing unwanted offers, etc. Unfortunallly, there is no such laws in eastern one... I found an answer (bugfix?) to my question as using my contacts in assigned block againist using client's one. But I still think that some fields in RIPE DB should be hidden from public access (for example, crypted MD5 password, business sensistive data like clients contacts and maybe other). Like changed: attribute is now. Many other DB's have public and private access now, and it is good. For example, russian domains .ru and .su (RIPN DB) show only contact information for domain owner, and other data like mandatory passport and registration address fields are hidden. -- ? ?????????, ?????? ?????? (MT6561-RIPE, 2:463/253 at FIDO) From dennis at gippnet.com Wed May 18 10:33:14 2005 From: dennis at gippnet.com (=?UTF-8?B?RGVubmlzIEx1bmRzdHLDtm0=?=) Date: Wed, 18 May 2005 10:33:14 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505171250.49445.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <4284FD80.1050202@bluewin.ch> <200505171250.49445.president@ukraine.su> Message-ID: <428AFDCA.7040305@gippnet.com> Yes indeed. But in the ideal world noone does nasty things. And yes. It would be better If all information was available at any time. Unfortunatly there will allways be people misusing this freedom so to say. So the only option would be to hide some fields from the public whois. But we need to count in, that this will decrease the usability of the DB in general. NIC-se introduced a system some years back where their registrars could log in to a full unrestricted whois. But on the other hand, displaying full info for LIR:s only would be a bit to sadistic. Maybe a sollution would be to bind complete db access to a legal contract, wich needs to be applied for? Best regards. --Dennis Lundstr?m GiPPNET AB, Stockholm Sweden Max Tulyev wrote: >Hello! > > > >>In most countries technical contacts don't decide which ISP to >>buy connectivity from... >> >> > >But technical peoples are that neck directing the head ;-) > > > >>Besides, there are other ways to find the info you want: >>- dig (nslookup) www.bibgcompany.su -> IP address >> whois IP address -> you know which ISP's customer the company is >>- dig (nslookup -type=SOA) bibgcompany.su (SOA) -> E-Mail address >> of responisble for dns >>- send mail to info at bigcompany.su ... >>- Meybe use a phone book and call in? >> >> > >Ofcource yes. But RIPE DB is amazing tool if an attack directed againist >certain ISP. > > > >>In western (european?) countries there are trade laws which don't allow >>address harvesting (especially whois entries and other public data), >>placing unwanted offers, etc. >> >> > >Unfortunallly, there is no such laws in eastern one... > >I found an answer (bugfix?) to my question as using my contacts in assigned >block againist using client's one. > >But I still think that some fields in RIPE DB should be hidden from public >access (for example, crypted MD5 password, business sensistive data like >clients contacts and maybe other). Like changed: attribute is now. > >Many other DB's have public and private access now, and it is good. For >example, russian domains .ru and .su (RIPN DB) show only contact information >for domain owner, and other data like mandatory passport and registration >address fields are hidden. > > > From jwkckid1 at ix.netcom.com Wed May 18 13:06:28 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Wed, 18 May 2005 04:06:28 -0700 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <4284FD80.1050202@bluewin.ch> <200505171250.49445.president@ukraine.su> <428AFDCA.7040305@gippnet.com> Message-ID: <428B21B2.76C72F81@ix.netcom.com> Dennis and all, Dennis Lundstr?m wrote: > Yes indeed. But in the ideal world noone does nasty things. And yes. It > would be better If all information was available at any time. > Unfortunatly there will allways be people misusing this freedom so to say. > So the only option would be to hide some fields from the public whois. Yes but which fields and why? > > But we need to count in, that this will decrease the usability of the DB > in general. NIC-se introduced a system some years back where their > registrars could log in to a full unrestricted whois. > But on the other hand, displaying full info for LIR:s only would be a > bit to sadistic. Why is such sadistic? > > Maybe a sollution would be to bind complete db access to a legal > contract, wich needs to be applied for? Bad idea here. More lawyers more problems... > > > Best regards. > > --Dennis Lundstr??m > GiPPNET AB, Stockholm Sweden > > Max Tulyev wrote: > > >Hello! > > > > > > > >>In most countries technical contacts don't decide which ISP to > >>buy connectivity from... > >> > >> > > > >But technical peoples are that neck directing the head ;-) > > > > > > > >>Besides, there are other ways to find the info you want: > >>- dig (nslookup) www.bibgcompany.su -> IP address > >> whois IP address -> you know which ISP's customer the company is > >>- dig (nslookup -type=SOA) bibgcompany.su (SOA) -> E-Mail address > >> of responisble for dns > >>- send mail to info at bigcompany.su ... > >>- Meybe use a phone book and call in? > >> > >> > > > >Ofcource yes. But RIPE DB is amazing tool if an attack directed againist > >certain ISP. > > > > > > > >>In western (european?) countries there are trade laws which don't allow > >>address harvesting (especially whois entries and other public data), > >>placing unwanted offers, etc. > >> > >> > > > >Unfortunallly, there is no such laws in eastern one... > > > >I found an answer (bugfix?) to my question as using my contacts in assigned > >block againist using client's one. > > > >But I still think that some fields in RIPE DB should be hidden from public > >access (for example, crypted MD5 password, business sensistive data like > >clients contacts and maybe other). Like changed: attribute is now. > > > >Many other DB's have public and private access now, and it is good. For > >example, russian domains .ru and .su (RIPN DB) show only contact information > >for domain owner, and other data like mandatory passport and registration > >address fields are hidden. > > > > > > -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From president at ukraine.su Fri May 20 08:33:42 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 20 May 2005 10:33:42 +0400 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <20050513100610.15fae76c@abramov.demos.ru> References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <20050513100610.15fae76c@abramov.demos.ru> Message-ID: <200505201033.42805.president@ukraine.su> Hi! New cup of gas on that fire ;) There is new database released: all bank transactions in Russia, IV quarter of 2004 (this is update to exist database from April 2003). It costs only $100 (source: http://top.rbc.ru/index.shtml?/news/policy/2005/05/20/20100238_bod.shtml). You can use it with RIPE DB and even see how much certain client pays for connection... > On Thu, 12 May 2005 17:11:21 +0400 > > Max Tulyev wrote: > > If my satisfied client will receive a tons of offers from other peoples > > just because of I show him in open database - it is really good??? > > > > Is it really good for me to look up the database and send that offers to > > others? > > I don't think that it's good for you to be a spammer :)) > But, if you wish to send UCE to "target auditory", you can also find this > "target auditory" from many over sources then RIPE DB.:) If your customer > exists in RIPE DB, or if it has meaningfull PTR records on used > addresses,it isn't gives someone advantage in stealing this customer from > you. -- ? ?????????, ?????? ?????? (MT6561-RIPE, 2:463/253 at FIDO) From dennis at gippnet.com Fri May 20 09:57:01 2005 From: dennis at gippnet.com (=?UTF-8?B?RGVubmlzIEx1bmRzdHLDtm0=?=) Date: Fri, 20 May 2005 09:57:01 +0200 Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <200505201033.42805.president@ukraine.su> References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <20050513100610.15fae76c@abramov.demos.ru> <200505201033.42805.president@ukraine.su> Message-ID: <428D984D.3050806@gippnet.com> Public records are wonderful, as they gives us ordinary people the possibility to check up on the folks we elect into government :-) But offcourse these could be missused. More importantly you guys should pass some legislation on harvesting public records, for marketing material. I'm no way a legal expert, but that seems more resonable. We got something simmular in Sweden called offentlighetsprincipen. Basicly all material passing a government agency are put in the public records. We could even look up if someone have been convicted of a fellony, and read court documents. And offcourse look up annual income, and get pictures of the person, if he/she applied for a passport. Cheers! --Dennis Lundstr?m GippNET AB, Stockholm Sweden Max Tulyev wrote: >Hi! > >New cup of gas on that fire ;) > >There is new database released: all bank transactions in Russia, IV quarter of >2004 (this is update to exist database from April 2003). It costs only $100 >(source: >http://top.rbc.ru/index.shtml?/news/policy/2005/05/20/20100238_bod.shtml). >You can use it with RIPE DB and even see how much certain client pays for >connection... > > > >>On Thu, 12 May 2005 17:11:21 +0400 >> >>Max Tulyev wrote: >> >> >>>If my satisfied client will receive a tons of offers from other peoples >>>just because of I show him in open database - it is really good??? >>> >>>Is it really good for me to look up the database and send that offers to >>>others? >>> >>> >>I don't think that it's good for you to be a spammer :)) >>But, if you wish to send UCE to "target auditory", you can also find this >>"target auditory" from many over sources then RIPE DB.:) If your customer >>exists in RIPE DB, or if it has meaningfull PTR records on used >>addresses,it isn't gives someone advantage in stealing this customer from >>you. >> >> > > > From rjetten at eunet.fi Fri May 20 10:36:14 2005 From: rjetten at eunet.fi (Raymond Jetten) Date: Fri, 20 May 2005 11:36:14 +0300 (EEST) Subject: [address-policy-wg] RIPE DB: disclosure of commertial information In-Reply-To: <428D984D.3050806@gippnet.com> References: <200505121539.25776.president@ukraine.su> <200505121711.21015.president@ukraine.su> <20050513100610.15fae76c@abramov.demos.ru> <200505201033.42805.president@ukraine.su> <428D984D.3050806@gippnet.com> Message-ID: And, not much of this has to do with address-policy anymore, somehow i feel the term spam coming up in my mind (?) rgds, -- ------ ___ -- Raymond Jetten Raymond.jetten at eunet.fi ----- / / / _ __ _/_ --- tel +358 3 41024139 ---- /-- / / / ) /__/ / ---- EUNet Finland fax +358 3 41024199 --- (___ (___/ / / (__ (_ ----- Tampere, Hermia gsm +358 45 6700139 -- ------ Network Engineer http://www.eunet.fi/ On Fri, 20 May 2005, [UTF-8] Dennis Lundstr?m wrote: > Date: Fri, 20 May 2005 09:57:01 +0200 > From: "[UTF-8] Dennis Lundstr?m" > To: Max Tulyev > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RIPE DB: disclosure of commertial information > > Public records are wonderful, as they gives us ordinary people the > possibility to check up on the folks we elect into government :-) > But offcourse these could be missused. More importantly you guys should pass > some legislation on harvesting public records, for marketing material. I'm no > way a legal expert, but that seems more resonable. > > We got something simmular in Sweden called offentlighetsprincipen. > Basicly all material passing a government agency are put in the public > records. > We could even look up if someone have been convicted of a fellony, and read > court documents. > And offcourse look up annual income, and get pictures of the person, if > he/she applied for a passport. > > Cheers! > > --Dennis Lundstr?m > GippNET AB, Stockholm Sweden > > Max Tulyev wrote: > >> Hi! >> >> New cup of gas on that fire ;) >> >> There is new database released: all bank transactions in Russia, IV quarter >> of 2004 (this is update to exist database from April 2003). It costs only >> $100 (source: >> http://top.rbc.ru/index.shtml?/news/policy/2005/05/20/20100238_bod.shtml). >> You can use it with RIPE DB and even see how much certain client pays for >> connection... >> >> >>> On Thu, 12 May 2005 17:11:21 +0400 >>> >>> Max Tulyev wrote: >>> >>>> If my satisfied client will receive a tons of offers from other peoples >>>> just because of I show him in open database - it is really good??? >>>> >>>> Is it really good for me to look up the database and send that offers to >>>> others? >>>> >>> I don't think that it's good for you to be a spammer :)) >>> But, if you wish to send UCE to "target auditory", you can also find this >>> "target auditory" from many over sources then RIPE DB.:) If your customer >>> exists in RIPE DB, or if it has meaningfull PTR records on used >>> addresses,it isn't gives someone advantage in stealing this customer from >>> you. >>> >> >> > > From iljitsch at muada.com Sat May 21 19:18:50 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 21 May 2005 19:18:50 +0200 Subject: [address-policy-wg] IPv4 allocation monitoring tool Message-ID: Hi, I've been looking at the IPv4 allocations lately, in order to figure out how soon we're going to run out. I made a little tool to search the data in different ways: http://www.bgpexpert.com/addrspace.php It doesn't do anything fancy: just collect the public stats from the different RIR FTP servers once in a while and dump the records in a database, which can then be searched with the page above, with results such as: RIR Country Addresses Date 78.51 M 2000 89.02 M 2001 69.02 M 2002 87.67 M 2003 123.93 M 2004 79.86 M 2005 Another interesting one: RIR Country Addresses Date US 1305.90 M JP 138.33 M EU 114.01 M Let me know if you have any questions or suggestions. Iljitsch van Beijnum From pwilson at apnic.net Mon May 23 02:41:37 2005 From: pwilson at apnic.net (Paul Wilson) Date: Mon, 23 May 2005 10:41:37 +1000 Subject: [address-policy-wg] IPv4 allocation monitoring tool In-Reply-To: References: Message-ID: <238A447342B09F94215D462D@as-paul.apnic.net> Dear Iljitsch > > I've been looking at the IPv4 allocations lately, in order to figure out > how soon we're going to run out. I made a little tool to search the data > in different ways: > > http://www.bgpexpert.com/addrspace.php Thanks for this. In publishing this data we have hoped that community members would make use of it in ways like this. > Another interesting one: > > RIR Country Addresses Date > > US 1305.90 M > JP 138.33 M > EU 114.01 M One caveat here, which some may not be aware of. The "EU" code represents allocations which are made by RIPE-NCC in Europe, but not specific to a country. Likewise, APNIC uses "AP" to denote similar allocations in the Asia Pacific region. Records featuring these codes (EU and AP) do NOT represent totals for all allocations in the region. To achieve this you need to add up allocations for all countries or economies you are interested in. Regards Paul ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 From ncc at ripe.net Tue May 24 14:09:07 2005 From: ncc at ripe.net (Nick Hyrka) Date: Tue, 24 May 2005 14:09:07 +0200 Subject: [address-policy-wg] RIPE 50 Report Message-ID: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> [Apologies for duplicate e-mails.] RIPE 50 Report Dear Colleagues, The RIPE 50 Meeting took place from 2 - 6 May 2005 at the Clarion Hotel, Stockholm, Sweden. There were over 375 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 50 included: - The successful implementation of the new RIPE Meeting format into three days on operational and technical content followed by two days on policy related issues. - An update on the ICANN ASO Address Council. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-fri-ac.pdf - A commentary on the ITU-T Proposal for National Address Registries for IPv6 by Geoff Huston, APNIC. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-itu-ipv6-proposal.pdf - Final discussion on the RIPE Policy Development Process. More information about this will appear on www.ripe.net shortly. Afilias, Arbor Networks, Cisco Systems, Force10 Networks, Netnod, NIKHEF, Nokia, TeliaSonera and the RIPE NCC are thanked for the support they provided to the meeting. TeliaSonera are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 50 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/index.html SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that the Address Policy Working Group Chairs will make a formal proposal that global policies should go through the RIPE Policy Development Process. - There was discussion on the TLD anycast allocation policy proposal, the IPv6 proposal to remove the 200 customers requirement, the proposal for removal of the Africa Special Policy, the proposal to add regional boundaries to policy documents and the IPv4-HD-Ratio proposal. ANTI-SPAM WORKING GROUP - There was discussion on whether ripe-206 should be revised to reflect the updates to the LINX BCP document that was used as the base for the original ripe-206. - There was discussion about anti-spammers sometimes behaving worse than spammers, and action placed on the Working Group Chair to start work on a document for best practise for spam complaints. DATABASE WORKING GROUP - It was agreed that a proposal on the "country:" attribute should be prepared. This will be done by the RIPE NCC. - It was noted that changes to the RIPE Database for abuse are now in production. DNS WORKING GROUP - It was agreed that the DNS Working Group Chair will produce a proposal to solve the problem that changes to reverse DNS nameservers cannot have multiple names. - There was discussion on whether the DNS Working Group should take over the work to produce a RIPE Document on AAAA resolution issues. - It was agreed that the RIPE NCC will produce statistics on anycast placement for K-root and the RIPE region Hostcount in time for RIPE 51. - It was noted that DNSSEC RFCs have been published, and that DNSSEC is being tested in Sweden in the .se domain. EIX WORKING GROUP - It was noted that the Switching Wish-List Version 3.0 will be published soon by Mike Hughes, and that version 3.1 will be published after RIPE 51. - There was discussion about public versus private peering. ENUM WORKING GROUP - It was agreed that Niall O'Reilly and Carsten Schiefner will be the new ENUM Working Group Chairs. - It was noted that the IETF is continuing work on ENUM standards. - It was agreed that the ENUM Working Group will continue to work as it has in the past, with an emphasis on the exchange of operational experience. IPV6 WORKING GROUP - It was decided that the RIPE Whois Database will continue to include more services that run in native IPv6. - It was agreed that the community needs to produce a revised Internet draft before RIPE 51 to formally address the demands of RFC3177, particularly the /48 recommendation. - It was noted that the IPv6 Working Group needs to decide where it wishes to house the new, operational IPv6 mailing list. RIPE NCC SERVICES WORKING GROUP - There was discussion on the value of the Hostcount. It was agreed that the RIPE NCC should continue working on this, and that the RIPE NCC should write and put a new Hostcount into service. ROUTING WORKING GROUP - There was discussion on route flap damping and de-aggregation practices raised by Philip Smith in the RIPE 50 Plenary. - Lorenzo Colliti (RIPE NCC) presented the research work of Roma Tre University on active BGP probing to discover AS level topology of the Internet. TEST TRAFFIC WORKING GROUP - It was agreed that the community should provide a proposal on how TTM infrastructure could be used to certify the quality of service provided by ISPs and to verify Service Level Agreements. - Henk Uijterwaal gave an update on the status of the TTM project - Thomas Wana presented work done to improve the accuracy of TTM time measurements and a proposal to create even greater accuracy by using DAG cards for measurement. - There was discussion on the future directions for the TTM project and it was agreed that the TTM infrastructure and measurements could be leveraged to certify the quality of service provided by ISPs. The Working Group agreed that the RIPE NCC, as a trusted third party, could perform the measurements and publish the results. CO-LOCATED PEERING BoF Netnod, LINX and AMS-IX hosted a peering BoF co-located at RIPE 50 on Sunday, 1 May, where peering policies were presented. CO-LOCATED LOBSTER TUTORIAL A tutorial entitled "Passive Network Traffic Monitoring" was organised on Friday, 6 May, by the consortium of LOBSTER, a European IST Project on Large-Scale Monitoring of Broadband Internet Infrastructures. RIPE 50 WEBCASTING AND ARCHIVES During RIPE 50, the RIPE NCC collected feedback from participants watching the webcast and listening to the audiocasts. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 50 are available at: http://www.ripe.net/ripe/meetings/ripe-50/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 50, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 50. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting . RIPE 50 REFERENCE PAGE A complete list of RIPE 50 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-50 RIPE 51 RIPE 51 will be held in Amsterdam, the Netherlands from 10 - 14 October 2005. Information on RIPE 51 is available at: http://www.ripe.net/ripe/meetings/ripe-51 If you have any questions about RIPE Meetings, please contact . From david.kessens at nokia.com Wed May 25 00:52:00 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 24 May 2005 15:52:00 -0700 Subject: [address-policy-wg] RIPE 50 Report In-Reply-To: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> References: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> Message-ID: <20050524225200.GB7177@nokia.com> Nick, I just sent a mail to the ipv6 wg list with some comments on this summary. I am going to cause some duplication with that other mail, but I believe it is important to keep the record straight. Please follow up on the ipv6 wg mailing list only to avoid further duplication. On Tue, May 24, 2005 at 02:09:07PM +0200, Nick Hyrka wrote: > > IPV6 WORKING GROUP > > - It was decided that the RIPE Whois Database will continue to include more > services that run in native IPv6. We did not make such a decision. We as the working group have no authority to tell the RIPE NCC what to do or not to do. At best we can recommend to the RIPE NCC to take a certain approach and this approach will in general be followed if there is no/little funding required, or otherwise, *if* the RIPE NCC membership agrees on funding such work. We discussed the issue and some people expressed their opinion that we want more than just a proxy service but we did not formally adopted a recommendation (since nobody asked to formally adopt such a recommendation). I am personally glad to hear that the RIPE NCC decided to make the mirroring service available in ipv6 though! Also, I appreciate that we don't have to formally adopt such recommendations as I think it makes for a much better working relationship where the RIPE NCC takes the initiative and picks up on ideas and discussions that happen in the working group without having to formally request the RIPE NCC to do so (policy issues are obviously a completely different matter!). > - It was agreed that the community needs to produce a revised Internet > draft before RIPE 51 to formally address the demands of RFC3177, > particularly the /48 recommendation. This is not what was agreed. It was agreed that it would be useful if an internet draft would be written that potentially could update rfc 3177. We did not discuss a specific timeline (but I don't think anybody would object if it would happen rather sooner than later). In addition, the text 'to formally address the demands of RFC3177' doesn't make any sense to me. I have no idea what that means as rfc 3177 didn't contain any demands. It was expressed by many that the /48 recommendation in rfc 3177 is perhaps a bit too generous and that this could potentially be addressed by adding another category smaller than a /48. However, we started the discussion to make it very clear that we were not going to make decisions during this meeting. It was solely intended to test the waters and get some general idea where people stand at this point in time. In addition, the discussion provided useful input so that a first draft would not be way out of line with current thinking of the RIPE community. > - It was noted that the IPv6 Working Group needs to decide where it wishes > to house the new, operational IPv6 mailing list. Again, the working group didn't decide this. It was brought up that a new mailing list was formed and we received several comments on this topic. Among others that it might not be ideal to have such a list being run by an enthiustic individual as it is important to keep mailarchives preserved even if the individual moves on to pursue other interests. However, this was a comment from the audience, not a decision by the working group. In relation to this topic, I just noticed that the working group website page now mentions: > There is also a global mailing list (not regional RIR/NOG) dedicated > to operational matters of the global IPv6 (production, not 6BONE) > Internet at: > > http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ > > If you are taking part in IPv6 BGP or are interested in global IPv6 > operational matters, please join the list. The purpose is to foster > exchange of experience and resolve problems which require non-local > coordination. The list is also available to discuss problems people > face while deploying IPv6. I did not request the RIPE NCC to put this information on the website neither did the working group endorse this mailing list in any form or way. David Kessens ipv6 wg chair ---