From francisco.guerreiro at acv.org.pt Wed Dec 15 03:55:42 2004 From: francisco.guerreiro at acv.org.pt (Francisco Guerreiro) Date: Wed, 15 Dec 2004 02:55:42 +0000 Subject: about ripe.db on ftp.ripe.net Message-ID: <41BFA7AE.3070407@acv.org.pt> Hi, I'm doing a statistic work on ripe.db for my University (Faculty of Science of the Lisbon University) and I downloaded ripe.db.inetnum (from the split files directory) so I can do statistics on several portuguese speaking countrys and Portugal itself. The ripe.db.inetnum suits my needs exactly but the admin-c: and tech-c: objects refer to person: objects which can't be found on ripe.db. I've googled a bit and found reference (back in 1993) of a split of ripe.db named ripe.db.person which probably had the additional information I need. Since I don't see that ripe.db.person anywhere on the ftp and the other .db files don't have person: objects, I was wondering if they were removed due to spam issues or something, since they're accessible through normal whois.ripe.net query's (which are bound to massive querying limits). Could someone shed some light into this matter? regards, Francisco Guerreiro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5261 bytes Desc: S/MIME Cryptographic Signature URL: From jeroen at unfix.org Wed Dec 15 09:57:19 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Dec 2004 09:57:19 +0100 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <41BFA7AE.3070407@acv.org.pt> References: <41BFA7AE.3070407@acv.org.pt> Message-ID: <1103101039.20370.7.camel@firenze.zurich.ibm.com> On Wed, 2004-12-15 at 02:55 +0000, Francisco Guerreiro wrote: > Hi, > I'm doing a statistic work on ripe.db for my University (Faculty of > Science of the Lisbon University) > and I downloaded ripe.db.inetnum (from the split files directory) so I > can do statistics on several > portuguese speaking countrys and Portugal itself. The ripe.db.inetnum > suits my needs exactly but > the admin-c: and tech-c: objects refer to person: objects which can't be > found on ripe.db. > I've googled a bit and found reference (back in 1993) of a split of > ripe.db named ripe.db.person > which probably had the additional information I need. > Since I don't see that ripe.db.person anywhere on the ftp and the other > .db files don't have person: > objects, I was wondering if they were removed due to spam issues or > something, since they're accessible through normal whois.ripe.net > query's (which are bound to massive querying limits). > Could someone shed some light into this matter? Afaik they where removed because people used them for mass marketing (thus including spam). Nevertheless for statistical analysis you can most likely do without that information anyway. Usually the person's are role's and/or generic mailboxes anyways. If you want to see the amount of 'same persons' you can also compare the handles themselves... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From woeber at cc.univie.ac.at Wed Dec 15 09:16:44 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Dec 2004 10:16:44 +0200 Subject: about ripe.db on ftp.ripe.net Message-ID: <00A3C617.A41D8596.22@cc.univie.ac.at> >> objects, I was wondering if they were removed due to spam issues or=20 >> something, since they're accessible through normal whois.ripe.net=20 >> query's (which are bound to massive querying limits). >> Could someone shed some light into this matter? > >Afaik they where removed because people used them for mass marketing >(thus including spam). Exactly. There's probably more than one way to still do what you think is useful or necessary: - try to select from the inet[6]num split files those entries which are "interesting" and query the contacts from the live DB (subject to Q limits - see next bullet) - talk to the DB operators (ripe-dbm at ripe.net), explain to them what you inted to do, and why, and get an exemption from the Q-limit - talk to the DB operators and explain what your want to do, and why, and ask for access to the "missing" person,... split file. This might solve your problem if you want to perform a snapshot analsys - if you want to run your analysis on a more regular basis, then getting an NRTM[1] set up at your site might be a better solution. This requires a formal agreement with the NCC about the DO's and DON'Ts, again talk to ripe-dbm. [1] Near(ly) Real Time Mirror. Hth, Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or 0::1/128 ?) From niall.oreilly at ucd.ie Wed Dec 15 12:09:57 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 15 Dec 2004 11:09:57 +0000 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <1103101039.20370.7.camel@firenze.zurich.ibm.com> References: <41BFA7AE.3070407@acv.org.pt> <1103101039.20370.7.camel@firenze.zurich.ibm.com> Message-ID: On 15 Dec 2004, at 08:57, Jeroen Massar wrote: > If you want to see the amount of 'same persons' you > can also compare the handles themselves... To some extent. A number of individuals have multiple handles. Possible reasons include: - no housekeeping after someone moved to a new job, - automatic introduction of new handles during bulk operations. Best regards, Niall O'Reilly PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 From jeroen at unfix.org Wed Dec 15 12:18:22 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Dec 2004 12:18:22 +0100 Subject: about ripe.db on ftp.ripe.net In-Reply-To: References: <41BFA7AE.3070407@acv.org.pt> <1103101039.20370.7.camel@firenze.zurich.ibm.com> Message-ID: <1103109502.20370.38.camel@firenze.zurich.ibm.com> On Wed, 2004-12-15 at 11:09 +0000, Niall O'Reilly wrote: > On 15 Dec 2004, at 08:57, Jeroen Massar wrote: > > > If you want to see the amount of 'same persons' you > > can also compare the handles themselves... > > To some extent. A number of individuals have multiple handles. > Possible reasons include: > - no housekeeping after someone moved to a new job, > - automatic introduction of new handles during bulk operations. In that case you should also assume that the handle itself contains wrong information, thus that it is useless either way ;) Especially now with the free creation of maintainers a lot more junk can and will likely be stored in the db and as it is maintained the junk will stay there too until the periodic email check is run again... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From woeber at cc.univie.ac.at Wed Dec 15 11:31:59 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Dec 2004 12:31:59 +0200 Subject: about ripe.db on ftp.ripe.net Message-ID: <00A3C62A.890CADE6.27@cc.univie.ac.at> >On 15 Dec 2004, at 08:57, Jeroen Massar wrote: > >> If you want to see the amount of 'same persons' you >> can also compare the handles themselves... > >To some extent. A number of individuals have multiple handles. >Possible reasons include: > - no housekeeping after someone moved to a new job, > - automatic introduction of new handles during bulk operations. - and ERX :-( As an example, submit a query on "Walter Kunft" ... >Best regards, > >Niall O'Reilly > >PGP key ID: AE995ED9 (see www.pgp.net) >Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 Wilfried. From francisco.guerreiro at acv.org.pt Wed Dec 15 16:47:30 2004 From: francisco.guerreiro at acv.org.pt (Francisco Guerreiro) Date: Wed, 15 Dec 2004 15:47:30 +0000 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <1103101039.20370.7.camel@firenze.zurich.ibm.com> References: <41BFA7AE.3070407@acv.org.pt> <1103101039.20370.7.camel@firenze.zurich.ibm.com> Message-ID: <41C05C92.4020309@acv.org.pt> Jeroen Massar wrote: >Nevertheless for statistical analysis you can most likely do without >that information anyway. Usually the person's are role's and/or generic >mailboxes anyways. If you want to see the amount of 'same persons' you >can also compare the handles themselves... > > well, if I'm asking about that information, it's because I need it. I don't care about the e-mail contact on the person: object, that's not useful information for my work. And I can't compare the handles since they are several per person, hence the need for the person db. regards, Francisco Guerreiro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5261 bytes Desc: S/MIME Cryptographic Signature URL: From jeroen at unfix.org Wed Dec 15 17:50:42 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Dec 2004 17:50:42 +0100 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <41C05C92.4020309@acv.org.pt> References: <41BFA7AE.3070407@acv.org.pt> <1103101039.20370.7.camel@firenze.zurich.ibm.com> <41C05C92.4020309@acv.org.pt> Message-ID: <1103129442.20370.67.camel@firenze.zurich.ibm.com> On Wed, 2004-12-15 at 15:47 +0000, Francisco Guerreiro wrote: > Jeroen Massar wrote: > > >Nevertheless for statistical analysis you can most likely do without > >that information anyway. Usually the person's are role's and/or generic > >mailboxes anyways. If you want to see the amount of 'same persons' you > >can also compare the handles themselves... > > > > > well, if I'm asking about that information, it's because I need it. > I don't care about the e-mail contact on the person: object, that's > not useful information for my work. I wonder what kind of research you are doing? Maybe indexing prefixes based on the administrative contact? Note that it is contact information, not the location of the prefix. Nor does it have any relation on location or whatsoever against the prefix in the database, thus I wonder what the value of that information could be, except for contact or direct marketing purposes... > And I can't compare the handles > since they are several per person, hence the need for the person db. 1 person can have multiple handles, but 1 handle maps to 1 person/role. And even if you had the info you would need to apply a very smart filter because if a person has multiple handles you can't do a direct match as a space extra, comma here, different address there and it already breaks your statistical analysis with incorrect assumptions. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From francisco.guerreiro at acv.org.pt Wed Dec 15 18:09:37 2004 From: francisco.guerreiro at acv.org.pt (Francisco Guerreiro) Date: Wed, 15 Dec 2004 17:09:37 +0000 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <1103129442.20370.67.camel@firenze.zurich.ibm.com> References: <41BFA7AE.3070407@acv.org.pt> <1103101039.20370.7.camel@firenze.zurich.ibm.com> <41C05C92.4020309@acv.org.pt> <1103129442.20370.67.camel@firenze.zurich.ibm.com> Message-ID: <41C06FD1.3080806@acv.org.pt> Jeroen Massar wrote: > >I wonder what kind of research you are doing? Maybe indexing prefixes >based on the administrative contact? Note that it is contact >information, not the location of the prefix. Nor does it have any >relation on location or whatsoever against the prefix in the database, >thus I wonder what the value of that information could be, except for >contact or direct marketing purposes... > > > It's for a university paper, the value of the information is the information itself, don't think about practical use for the information, since the practical use is actually writing the paper :) The person(s) who is the admin-c/tech-c or the company behind it, that's the prime of information I want. >1 person can have multiple handles, but 1 handle maps to 1 person/role. >And even if you had the info you would need to apply a very smart filter >because if a person has multiple handles you can't do a direct match as >a space extra, comma here, different address there and it already breaks >your statistical analysis with incorrect assumptions. > > well, I had to apply a filter to ripe.db.inetnum too :) that's no biggie, best to do is to read a little bit of the whole db, do a parser for common entry's and separate them from different ones. on the person case, it's just a matter of stripping/converting some characters and tolower() them. After that, I can right the regex I need to parse the data and store it on a sql db :) then, it's just a matter of making concept relations between the collected data. Internet Contact information is of no use to me since if any contact with any company should be made in the future on this or other papers, it would be through registered 'snail' mail, as one should always do (at least if you live in Portugal :D) in official communications between Companys/Universitys. It's funny because the actual contact information is of no use to me anyway, if any contact would be made, I'd have to phone the company to find out the person who deals with that kind of mail and address it to that person, or it would be simply discarded. So, as I think I made it clear, my intentions aren't those of a spammer/whatever-alike, I just need legitimate information that's not (that) available anymore due to bad use of it (i guess). regards, Francisco Guerreiro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5261 bytes Desc: S/MIME Cryptographic Signature URL: From francisco.guerreiro at acv.org.pt Wed Dec 15 16:47:57 2004 From: francisco.guerreiro at acv.org.pt (Francisco Guerreiro) Date: Wed, 15 Dec 2004 15:47:57 +0000 Subject: about ripe.db on ftp.ripe.net In-Reply-To: <00A3C617.A41D8596.22@cc.univie.ac.at> References: <00A3C617.A41D8596.22@cc.univie.ac.at> Message-ID: <41C05CAD.5090708@acv.org.pt> > - talk to the DB operators and explain what your want to do, and why, > and ask for access to the "missing" person,... split file. > This might solve your problem if you want to perform a snapshot > analsys > > I think I'll try that since I don't really want any e-mail address that shows on the role/person object, they could probably give me a 'recent' snapshot of the split file. > - if you want to run your analysis on a more regular basis, then getting > an NRTM[1] set up at your site might be a better solution. > This requires a formal agreement with the NCC about the DO's and > DON'Ts, again talk to ripe-dbm. > > I thought of that too, but my analisys is restricted to Portugal and portuguese speaking countrys, which represents less than 1% of the whole database and I would be using so much useless bandwidth and I think there's enough pointless traffic on the internet :) I'll try to contact the db operators, thanks for your suggestions! regards, Francisco Guerreiro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5261 bytes Desc: S/MIME Cryptographic Signature URL: From k13 at nikhef.nl Tue Dec 21 14:44:13 2004 From: k13 at nikhef.nl (Rob Blokzijl) Date: Tue, 21 Dec 2004 14:44:13 +0100 (MET) Subject: Announcement: Policy Development Process in RIPE Message-ID: To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list at ripe.net - if you are not subscribed to ripe-list at ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair at ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman From randy at psg.com Tue Dec 21 18:05:57 2004 From: randy at psg.com (Randy Bush) Date: Tue, 21 Dec 2004 12:05:57 -0500 Subject: [eix-wg] Announcement: Policy Development Process in RIPE References: Message-ID: <16840.22517.647024.632059@roam.psg.com> > later today I will publish a draft document that describes the policy > making process in RIPE. this is the product of the small working group on the subject? randy From k13 at nikhef.nl Wed Dec 22 15:43:43 2004 From: k13 at nikhef.nl (Rob Blokzijl) Date: Wed, 22 Dec 2004 15:43:43 +0100 (MET) Subject: Draft Document: Policy Development Process in RIPE Message-ID: Policy Development Process in RIPE R.Blokzijl 21 December 2004 1. Introduction Since its creation in 1989, RIPE has from time to time agreed on common practices. These common practices may come in different forms and/or under different names: - best common practice (or BCP), - recommendations to the community, - requests to the RIPE NCC, - recommendations to the RIPE NCC, - or just policy. In this document they are all called 'Policy'. The process that results in a policy has a few important and fundamental principles: a. it is open to all. Everyone interested in the wellbeing of the Internet may propose a policy, and take part in the discussions. b. it is transparent. All discussions and results are documented and freely available to all. c. conclusions are reached by consensus. This process has worked quite well over the years. This document does not seek to change that. What this document does try to accomplish is a description of the process that will improve its management. 2. The Process. In the process of developping a policy several distinct phases are identified: 1. Proposal Phase 2. Discussion Phase 3. Review Phase 4. Concluding Phase Each of these phases are detailed below. The whole process is summarised in a diagram, attached as Appendix A. This diagram contains timelines for the various stages of the process. These timelines are meant as defaults, or minimum timelines: individual proposals may define their own timelines. 2.1 Proposal Phase Discussions may be started by anyone at any time. Participants are welcome to discuss broad ideas as well as make detailed policy proposals. Proposals are made using a Policy Proposal template [TEMPLATE Appendix B]. The template forms a structure for the proposal. It details the reason for the proposal and any perceived consequences of the proposal. The RIPE NCC (the RIPE community's secretariat) identifies proposals with a number and publishes them in the appropriate section of the relevant working groups web pages. The page will indicate the version history and status of proposals: - Open for Discussion; - Agreed or - Withdrawn. Anyone that wants to draft a policy proposal may seek assistance from the RIPE NCC. The RIPE NCC will provide relevant facts, statistics and an assessment of the work involved in implementation of a proposal. The RIPE NCC will also assist with the drafting of text if its editorial services are required. A proposal is usually submitted via the chair of the relevant working group of RIPE. In case a working group can not easily be identified, the proposal may be submitted to the RIPE Chair. 2.2 Discussion Phase. Once a proposal has been submitted it will be announced on a dedicated mailing list to which anybody can subscribe: . This announcement will also indicate where discussion on this proposal will take place. Usually this will be the relevant working group mailing list. Where a policy change would result in an amendment to a published policy document, the textual changes are initially published as a draft document for community review and comment. There may be multiple iterations of a draft document if there is significant comment and change suggested. The discussion phase will have a limited time period, but not less then four weeks. 2.3 Review Phase Following the conclusion of the comment period the RIPE Working Group Chair determines whether the working group has reached consensus. If consensus has not been reached then the proposer may decide to withdraw the proposal. Alternatively, a new round of discussion and documentation may occur. 2.4 Concluding Phase When the RIPE Working Group Chair determines that the working group has reached a consensus, s/he moves the proposal to a Last Call for comments. The Last Call announcement is posted to the working group mailing list, the Last Call announcements mailing list and Chairs of all working groups. At the end of the Last Call period the working group chairs will decide together whether a consensus has been achieved If a consensus has been achieved, the RIPE NCC will announce the decision of the RIPE Working Group Chairs and implement the policy, if needed. If consensus has not been achieved the proposer (or anyone else) is free to return the proposal to the working group for further discussion. [TEMPLATE Appendix B] 1. Number (assigned by the RIPE NCC) 2. Policy Proposal Name: 3. Author a. name: b. e-mail: c. telephone: d. organisation: 4. Proposal Version: 5. Submission Date: 6. Suggested WG for discussion and publication 7. Proposal type: a. new, modify, or delete. 8. Policy term: a. temporary, permanent, or renewable. 9. Summary of proposal 10. Policy text a. Current (if modify): b. New: 11. Rationale: a. Arguments supporting the proposal b. Arguments opposing the proposal -------------- next part -------------- A non-text attachment was scrubbed... Name: timeline.pdf Type: application/pdf Size: 19644 bytes Desc: URL: From Ed.Lewis at neustar.biz Wed Dec 22 21:39:30 2004 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 22 Dec 2004 15:39:30 -0500 Subject: Draft Document: Policy Development Process in RIPE In-Reply-To: References: Message-ID: One comment leaps to mind... > Policy Development Process in RIPE > 2.4 Concluding Phase > If a consensus has been achieved, the RIPE NCC will announce the > decision of the RIPE Working Group Chairs and implement the policy, > if needed. I think this isn't the true end of the story of a "successful" policy proposal. Once a policy is approved (consensus achieved), I'd suggest that the RIPE NCC staff provide an estimated time until a policy is implemented and give updates on the implementation process. Some policies may be put into action quickly, some may require some design and implementation. Maybe the answer to my request is to publish appropriate-depth project plans for policy implementation and follow up with a milestone (progress) chart. Maybe the answer is to have a simple scoreboard showing whether a policy is in effect (green light) or still under development (yellow light). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield From saskia at ripe.net Wed Dec 22 16:23:48 2004 From: saskia at ripe.net (Saskia van Gorp) Date: Wed, 22 Dec 2004 16:23:48 +0100 Subject: RIPE NCC closed on December 24 Message-ID: <5.2.1.1.2.20041222154200.057d5d80@mailhost.ripe.net> Dear Colleagues, Our offices are closed on Friday 24 December 2004. We will reopen on Monday 27 December 2004. Our offices close on all Dutch public holidays listed at: http://www.ripe.net/ripencc/about/public-holidays.html Regards, Saskia van Gorp Front Office Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: