From hph at online.no Wed Jan 3 13:09:17 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 3 Jan 2001 13:09:17 +0100 Subject: Fw: RFC 3021 on 31-Bit Prefixes on IPv4 Links Message-ID: <012001c0757d$fef56230$ed05e1c3@hph> FYI. ----- Original Message ----- From: "RFC Editor" To: Cc: Sent: Monday, December 18, 2000 7:31 PM Subject: RFC 3021 on 31-Bit Prefixes on IPv4 Links > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3021 > > Title: Using 31-Bit Prefixes on IPv4 Point-to-Point Links > Author(s): A. Retana, R. White, V. Fuller, D. McPherson > Status: Standards Track > Date: December 2000 > Mailbox: aretana at cisco.com, riw at cisco.com, > vaf at valinor.barrnet.net, danny at ambernetworks.com > Pages: 10 > Characters: 19771 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-retana-31bits-03.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc3021.txt > > > With ever-increasing pressure to conserve IP address space on the > Internet, it makes sense to consider where relatively minor changes > can be made to fielded practice to improve numbering efficiency. One > such change, proposed by this document, is to halve the amount of > address space assigned to point-to-point links (common throughout the > Internet infrastructure) by allowing the use of 31-bit subnet masks > in a very limited way. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST at IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info at RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT00280.dat Type: application/octet-stream Size: 102 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rfc3021.txt URL: From hph at online.no Sun Jan 7 19:54:58 2001 From: hph at online.no (Hans Petter Holen) Date: Sun, 7 Jan 2001 19:54:58 +0100 Subject: lir-wg open actions & call for agenda items for RIPE 39 References: <017601c053c9$58124c60$7f05e1c3@hph> Message-ID: <01fe01c078db$55e70bb0$0600000a@hph> Dear working group, here is an updated version of our action list. The open items + items submitted by you ower the next couple of days will form the agenda for the upcoming meeting. I have asked for 3 timeslots this time: http://www.ripe.net/ripe/meetings/current/ripe-38/ripe38-plan.pdf Tues 1600 1730 Lir-wg: Global issues Wed 0900 1030 Lir-wg: Regional issues Wed 1100 1230 Lir-wg: Regional issues I have also discussed with the registries that it probably does not make sense that they give their registry reports twice, both in the local-ir wg and in the plenary, but that we instead focus on specific (policy) issues in the working group. > 35.1 Chair Publish policy document 35 pres Done: http://www.ripe.net/ripe/wg/lir/howto_devolep.html This is a short description of the current policy formation process in RIPE. > 35.2 Chair publish election procedure 35 pres Done: http://www.ripe.net/ripe/wg/lir/r37-adress_council.html > 35.4 NCC PGP Key exchange procedure RIPE38 > 35.5 NCC Implement PGP for hm RIPE38 > 36.5 Chair Assignment window applied on infrastructure > 36.6 AP Collect arbitrators Started > 36.7 NCC Keep lir-wg updated on pre RIR address space changes Ntr ? > > 38.1 WG Further discuss restoring the transparency > 38.2 NCC Incorporate IESG/IAB proposal into IPv6 policy > 38.2 M17 Work with the RIPE NCC to implement suggestions Ongoing, > 38.3 WG Nominate candidates for AC election Done: http://www.ripe.net/ripencc/about/regional/docs/nominees_jan2000.html > 38.4 Rob Perform election of AC candidate at RIPE 38 Plenary Initiated: On the RIPE 39 Plenary agenda. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html From david at IPRG.nokia.com Fri Jan 12 04:06:37 2001 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 11 Jan 2001 19:06:37 -0800 Subject: final version of the IPv6 joint policy meeting minutes Message-ID: <20010111190637.E460@iprg.nokia.com> Hi, Please see below for the final version of the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The only changes made to the draft are typographical. I would like to thank Vesna for taking the minutes. Thanks, David K. --- IPv6 joint policy meeting RIPE ipv6-wg & lir-wg Wednesday, 13 September 2000 RIPE 37 Chair: David Kessens Agenda i Statement of current policy draft ii IAB/IESG recommendations iii Panel discussion iv AOB =i= Statement of current policy draft -- Joao Damas, RIPE NCC One year ago 3 Regional Internet Registries produced document that outlines allocation of IPv6 address space. * size of end user assignments * multihoming considerations * what is the meaning of 80% usage in ipv6? We need the clear picture of these issues to move forward. [chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as possible, but he is not the official spokesman of those bodies] = ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocations size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy Multihoming: IETF is still looking for input on this issue. = iii= Panel discussion: 1. Stephen Burley (UUNET) 2. Steve Deering (ipng) 3. Joao Damas (RIPE NCC) 4. Bob Hinden (ipng) 5. Randy Bush (ngtrans) 6. Juergen Rauschenbach (ipv6 forum) Q: What is criteria for ISP allocation? How much IPv6 address space does an ISP get? A: (Randy) This proposal is not changing other parts of policy. All will still get a /35. Normal slow start. Q: (Dave Pratt) Could you clarify what is meant by the 80% rule? A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the subscribers) Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing hierarchy. It's difficult to build in hierarchy if aiming for 80% utilisation before more addresses will become available. Steve: H-ratio may be more appropriate rather than a percentage. A: I would suggest 20%. For example with 20% you can reserve addresses for 8 regions, and not worry if 6 of the 8 sites have small take up rates. A: (Steve) "you can start without hierarchy, and then add it later when the need arises". A: We could add hierarchy later, but maybe not really (same problems later as at start). We should be designing our networks correctly from the beginning. A: Discussion of possibility of H ratio's also being applied also to the LIR/ISP address range. Randy points out that with allocating /48s in a /35, the H ratio might be different, but the principle still holds, and there is a believe that there are enough addresses in IPv6 (also mentions in passing that the same believe existed in the early days of IPv4) Q: (Wilfried Woeber) Thank you for the clear document and clarification. Remaining issue: number of bits available for infrastructure. There should be a recommendation to start with the least significant bits. A: (Steve) We need an analysis regarding building an efficient hierarchy in the top 8 bits. If the community agrees on the /48 boundary, we may have to review the size of the initial allocation (/35 subTLA size). Joao explains why the /35 has been chosen. One gets 8192 NLA ranges, which can each by itself be structured and managed. This means it is actually more than if one gets a /19 in IPv4. Randy wonders why WW thinks one has a different problem in v6 than today in v4. The ISP he works for aggregates per pop, very strict and successful about it, but announce a /19 or shorter per pop. /35 feels as comfortable. Tries to understand if people don't feel comfortable with that and why. A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem is the 80% usage rate. Randy: isn't the problem the percent, not matter how much it is? A: Problem is if the pops grow at different speed. A: Gert Doering, space net, Germany: We started with /19. By now, we have /16 and few /19:s, and they are not aggregated. We have resellers, and they have theirs. It fragments awfully. I am in favour of /56; or, I do not mind /48 if we can get bigger prefix (more bits) in the front. I do not need more space, but more possibility to build the hierarchy and aggregate. Joao: You have /29 contiguous block reserved to grow into. Gert: I don't see the need for slow start. There are so many /29s that the routing tables would explode before the /29s were exhausted. Bob suggests that might be solvable by rethinking the 80% usage rate (so that ISPs are not penalised for taking a long-term view from the start). Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places, and announces same /35 at both places and Jurgen does not know to which one to send traffic. Chair: Want to refocus back on the recommendations of the draft. People seem to be OK with the /48. Let's move on. Need to come up with something to put in the multihoming section. For now, IPv4 method of multihoming should be used, as a short term recommendation. There is also the option to use multiple prefixes. The philosophy should be that addresses are cheap, so if someone wants to experiment with the multi address multihoming, let them and give them the addresses. Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come from provider assigned space. I think this is a good rule (until better multihoming techniques are developed) that should be continued for IPv6. Alain Durand: Wants to emphasise that it's early in deployment and we need lots of feedback regarding whether multihoming techniques etc work. Be generous with /48s. Randy: From the proposal "if they need more address space, they get multiple /48:s". I would suggest /47. Steve: Looking to create a team to investigate how to measure usage. Maybe find a H ratio measure to apply instead of the 80% rule. Joao: the conservation is not the only issue here. WW: We want to keep the routing table small. (...) Randy: Small number of providers having TLA does not look good from the market point of view and it would create the small club who owns the Internet. A: The requirement is not only to aggregate well (shrinks the table), but also to find neutral mechanism of allocation; how to get into that club. Chair: Do you have enough info on /48 proposal? (yes) Chair: OK recommendation of this group is that /48 assignments should go ahead. This will be taken to ARIN and APNIC. From jhma at KPNQwest.net Mon Jan 15 14:58:47 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Mon, 15 Jan 2001 14:58:47 +0100 Subject: LIR-ALLOCATED revisited Message-ID: <200101151358.OAA29652@aegir.EU.net> LIR and DB Working Groups (with apologies for duplicate email), Discussed at RIPE-34 but with little subsequent action, I would like to repropose the addition of LIR-ALLOCATED as a valid status value for inetnum objects in the RIPE database. Attached is a slightly revised version of the document ("troff -ms" source version available on request) I last posted a year ago as a result of LIR-WG Action LIR-34.8. The suggestion then was that this could be massaged into a RIPE document (I think dfk volunteered!) to update ripe-185 (European Internet Registry Policies and Procedures) and that support for the new value be added to the database (and NCC tools as necessary). Regards, James -- Senior Network Engineer, IP Archictecture Group, KPNQwest Singel 540, 1017 AZ Amsterdam, NL ----------cut here---------- "Status: LIR-ALLOCATED" Considered Useful James Aldridge ----- -------- This document proposes a new value for the status field of the inetnum object in the RIPE database in addition to those listed in sections 3.4.2 (PA vs PI space) and 4.4 (Allocation Registration) of the "European Internet Registry Policies and Procedures" document ripe-185. For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). -2- An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGYZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGYZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - REGY-MNT in this case. There is also a mnt- lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The final inetnum object here is a final assignment from the national organisation to a customer. From awo at atm.com.pl Tue Jan 16 21:06:56 2001 From: awo at atm.com.pl (Adam Obszynski) Date: Tue, 16 Jan 2001 21:06:56 +0100 Subject: No subject Message-ID: <159280505054.20010116210656@atm.com.pl> Hello , I want to ask about PI assigned address space. The best example is my own one which good show us bad idea of assigning exactly size than user require.. Today we got very bad organisation in world BGP table.. a lot of bad aggregated prefixes etc.. so carrier providers from day to day 8-) move filter mask to right... now ie. Sprint: http://www.sprint.net/policy/bgp_filters.html: [...] Customers may announce routes as small as /26 for IP address blocks obtained through Sprint. Announcements for blocks obtained from other providers are limited to a /24 or smaller mask (/23, /22 etc.). This applies only to Sprint customers; peers are bound by a much stricter prefix policy. [...] so if RIPE will assing PI requests addresses exactly as written in ripe-141 from we give our clients big chance that they will be filtered. The of course aware about it .. but.. when we have /24 we got 70% chance to filtered with.... ie. /26 we got 40% and less.. so it can effect in one bad situation.. ripe forms written for PI assign policy and requests of /24 or smaller for route security and out customers become unhappy... IMHO one way is change our LAW to be good for mass not for goverment only 8-) so i please you to made some updates and assign PI depend on actually known filtered size in carrier networks... in europe and whole world PS: sorry for my bad english and grammar 8-| here is some sentences from ripe-127 8-) thank you! [bof] [...] Document: ripe-127 Assignment Policies [...] ments etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 8 bits of address space to be assigned. [...] Detailed Recommendations [...] Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assignment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is ____________________________________________________ ripe-127.txt Page 7 [eof] -- Regards, Adam Obszy?ski ATM Inc. +48-22-5156418 From ncc at ripe.net Wed Jan 17 15:37:58 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 17 Jan 2001 15:37:58 +0100 Subject: ANNOUNCEMENT: Tools BOF at RIPE 38 Message-ID: <200101171437.PAA22428@office.ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce a 'Tools' BOF to be held at the RIPE 38 meeting in Amsterdam - please see: http://www.ripe.net/ripe/meetings/current/ripe-38/index.html This BOF session has been organised in order to discuss the tools we currently provide for our members, tools we plan to provide in the future and tools our members would like us to provide. 'Tools' refers to both software that the RIPE NCC makes available to its members to run themselves ( such as asused ) and software the RIPE NCC hosts that is used by the membership ( such as the Web page for checking European IP Address Space Request ( ripe-141 ) Forms and the Hostmaster mail robot ). Here is the Draft Agenda for this session: Proposed Agenda for the Tools BOF, RIPE 38 ------------------------------------------ Date: Tuesday 23rd January, 2001 Time: 14:00-15:30 Chair: Maldwyn Morris, Software Manager, RIPE NCC Location: St John I 0. Introduction 1. Existing tools 2. Tools in development 3. Proposals for tools I look forward to welcoming you to this BOF at the upcoming RIPE meeting. Cheers, Maldwyn Morris Software Manager RIPE NCC From CMijangosR at uni2.es Fri Jan 19 11:02:47 2001 From: CMijangosR at uni2.es (Mijangos Rodriguez, Carmen) Date: Fri, 19 Jan 2001 11:02:47 +0100 Subject: X-NCC-RegID:es.uni2 Message-ID: <1FB73D3CDA3DD311BC9A00902765123901BB761F@M1CORREO2> Hello: I'm not sure if I can ask the next questions in this mail-box, if It is not possible my apologise. I have some questions: 1) When we ask for a group Address assignment, have we to detail how many objects we are going to create?, or if all the objects have the same netname is enough with one object? 2) When we ask for some Address assignment and a hostmater send us a mail to accept this request, A- We have to create the objects of all this addresses very soon or we have some time to create the objects? How much time? B- Can we combine this approved address with other existing assignments ? 3) About the reverse delegation, we have two objects domain: 37.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es .... domain: 36.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es With this objects when arrive to RIPE a request reverse delegation of this address RIPE send to our "nserver: m2dnsnet1.net.uni2.es" this request. If we create other reverse delegation in RIPE of our addresses for a customer, for example: domain: 255.37.62.in-addr.arpa nserver: "customer_server" nserver: m2dnsnet1.net.uni2.es Now when arrive to RIPE a request reverse delegation of this address, 62.37.225.0 - 62.37.225.255 RIPE send to "customer_server" this request, and the rest of the request of address 62.36.0.0 - 62.37.255.255 are sent to our "nserver: m2dnsnet1.net.uni2.es". Is correct all this?? Thanks in advance Kind regards Carmen Mijangos Carmen Mijangos UNI2 - T?cnico de Servicios de datos Direcci?n T?cnica Tel?fono : +34 912520972 / M?vil: +34 667493879 e-mail: CMijangosR at uni2.es http://www.uni2.es From db-news at ripe.net Fri Jan 19 14:33:01 2001 From: db-news at ripe.net (RIPE Database Announcements) Date: Fri, 19 Jan 2001 14:33:01 +0100 Subject: Announcement: RIPE Whois Database Version 3.0beta2 released Message-ID: <200101191333.OAA14576@x51.ripe.net> Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC From arnold.nipper at de-cix.net Fri Jan 19 15:10:25 2001 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Fri, 19 Jan 2001 15:10:25 +0100 Subject: Announcement: RIPE Whois Database Version 3.0beta2 released References: <200101191333.OAA14576@x51.ripe.net> Message-ID: <003101c08221$bf161140$0190a8c0@nipper.de> rpsl.ripe.net doesn't seem to exist ... whois -h whois rpsl.ripe.net Daniele Arena whois: whois: Unknown host: Datei oder Verzeichnis nicht gefunden Let's have a look ... ;; ANSWER SECTION: rpsl.ripe.net. 1d23h59m55s IN CNAME reimp.ripe.net. reimp.ripe.net. 1d23h59m55s IN CNAME orange.ripe.net. orange.ripe.net. 1d23h59m55s IN A 193.0.1.239 Yeah, don't do that. Don't use CNAME to CNAME. Pls fix, Arnold ----- Original Message ----- From: "RIPE Database Announcements" To: ; ; ; ; ; Sent: Friday, January 19, 2001 2:33 PM Subject: Announcement: RIPE Whois Database Version 3.0beta2 released > > Dear All, > > This mail is to inform you that version 3.0beta2 of the RIPE Whois > Database software has been released. This is mainly a bugfix release in > respect to the "beta1" version. > > We remind you that the RIPE Database is about to change its data format, > from RIPE181 to RPSL (the Routing Policy Specification Language, see > RFC2622). This will affect all object types, including "person", "domain" > and "inetnum". > > We suggest you to start to get used to RPSL and version 3.0 . > Please check our RIPE-181 to RPSL Migration page at: > > http://www.ripe.net/rpsl/ > > You can test your skills with RPSL and the functionality of the new > beta release in the following ways: > > - Query rpsl.ripe.net at port 43. You will find there > exactly the same objects that are in whois.ripe.net, > mirrored live and in RPSL format. > > - If you have any script that runs by querying whois.ripe.net, > test it by pointing it to rpsl.ripe.net and make it > v3.0-compliant. > > - Try our CGI interface to the RPSL server: you can find it at > http://www.ripe.net/ripencc/pub-services/db/reimp/. > > - Get to know the new update path: use our "sandbox" database for > RPSL updates. Send your updates to and > query the corresponding database at rpsl.ripe.net, port 4343 . > > Remember that in a few months, that's the way the RIPE Database will be > running; so the earlier you start working with it, the less likely you are > to be unpleasantly surprised later. > > For those running Near-Real-Time Mirrors of the RIPE Database, please be > advised that as soon as the RIPE Database changes its data format, you > will not be able to mirror the RIPE Database using the version 2 of the > Software, since it is not RPSL-compliant. You will have to upgrade to > version 3 to mirror the RIPE Database. Please contact > for detailed information. > > Please note that the software is still in a "beta" phase. So we need your > feedback! If you happen to find something that looks like a bug when you > are testing the RPSL database, don't hesitate... > Send us a bug report at ! > > If you want to actively participate to the migration effort, you could > join the "RIP migration Task force" and let yourself be heard. Just write > to and ask to join the Task Force. > > You can download the latest release of the source code at the following URL: > > ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz > > You can also join a discussion list related to version 3.0 beta of the > RIPE Database Software. To subscribe to this list, send a message to > with the line: > > subscribe db-beta > > in the body of your letter. It is a moderated mailing list so some delays > in subscription are possible. > > > Regards, > > Daniele Arena > ___________________ > RIPE Database Group > RIPE NCC > > From beri at kpnqwest.net Sun Jan 21 19:48:45 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Sun, 21 Jan 2001 19:48:45 +0100 (CET) Subject: URGENT: Database problems? Message-ID: Dear RIPE NCC colleagues, I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, but can someone, please, take a look on the database update queue? Either the queue is full or the automatic email robot is broken. We sent an update of AS-KPNQWESTRO few times since Friday and no answer we got from the robot. That's 3 (three) days !!!!!!!!! Thanks! Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From andrei at ripe.net Sun Jan 21 21:24:28 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Sun, 21 Jan 2001 21:24:28 +0100 Subject: URGENT: Database problems? References: Message-ID: <3A6B457C.BD1944C7@ripe.net> Dear Berislav Todorovic, Unfortunately we experience some delay with processing updates, indeed. This is caused by re-indexing of person objects in the database which took longer than usual. Re-indexing is a normal procedure that is run over the weekends. Sometimes, due to the interference with some patterns of queries, it takes longer than expected. While this process is running updates are blocked. Your updates are queued (as we can see, the latest one is from Saturday afternoon) and will be processed as soon as re-indexing finishes (should take another 4 hours). We are sorry for the inconvenience, Best regards, Andrei Robachevsky DB Group Manager RIPE NCC Berislav Todorovic wrote: > > Dear RIPE NCC colleagues, > > I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, > but can someone, please, take a look on the database update queue? Either > the queue is full or the automatic email robot is broken. > > We sent an update of AS-KPNQWESTRO few times since Friday and no answer we > got from the robot. That's 3 (three) days !!!!!!!!! > > Thanks! > > Beri > > --------- Berislav Todorovic, Network Engineer --------- > ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- > ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- > --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- > -- Email: beri at kpnqwest.net <=> beri at EU.net -- > --- _ _ ____ _ .--. ____ ____ __/_ --- > ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From Sam.Mortimer at netservices.eng.net Fri Jan 19 15:39:26 2001 From: Sam.Mortimer at netservices.eng.net (Sam Mortimer) Date: Fri, 19 Jan 2001 14:39:26 -0000 Subject: Announcement: RIPE Whois Database Version 3.0beta2 released Message-ID: <5077C366EC86D31182150050044EE03B1FD363@NETEXCH01> > From: Nipper, Arnold [mailto:arnold.nipper at de-cix.net] > Sent: 19 January 2001 14:10 > > rpsl.ripe.net doesn't seem to exist ... > > whois -h whois rpsl.ripe.net Daniele Arena > whois: whois: Unknown host: Datei oder Verzeichnis nicht gefunden > > Let's have a look ... > > ;; ANSWER SECTION: > rpsl.ripe.net. 1d23h59m55s IN CNAME reimp.ripe.net. > reimp.ripe.net. 1d23h59m55s IN CNAME orange.ripe.net. > orange.ripe.net. 1d23h59m55s IN A 193.0.1.239 > > Yeah, don't do that. Don't use CNAME to CNAME. Pls fix, CNAME to CNAME is fine. it's used all the time with reverse DNS. works fine for me. Regards, -Sam. From arnold.nipper at de-cix.net Fri Jan 19 16:27:30 2001 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Fri, 19 Jan 2001 16:27:30 +0100 Subject: Announcement: RIPE Whois Database Version 3.0beta2 released In-Reply-To: <5077C366EC86D31182150050044EE03B1FD363@NETEXCH01> References: <5077C366EC86D31182150050044EE03B1FD363@NETEXCH01> Message-ID: <20010119162730.A2617@gateway.nipper.de> On Fri, Jan 19, 2001 at 02:39:26PM -0000, Sam Mortimer wrote: > > From: Nipper, Arnold [mailto:arnold.nipper at de-cix.net] > > Sent: 19 January 2001 14:10 > > > > rpsl.ripe.net doesn't seem to exist ... > > > > whois -h whois rpsl.ripe.net Daniele Arena ------------^^^^^^^^^^^^^^^^^^^^ > > whois: whois: Unknown host: Datei oder Verzeichnis nicht gefunden > > > > Let's have a look ... > > > > ;; ANSWER SECTION: > > rpsl.ripe.net. 1d23h59m55s IN CNAME reimp.ripe.net. > > reimp.ripe.net. 1d23h59m55s IN CNAME orange.ripe.net. > > orange.ripe.net. 1d23h59m55s IN A 193.0.1.239 > > > > Yeah, don't do that. Don't use CNAME to CNAME. Pls fix, > > CNAME to CNAME is fine. it's used all the time with reverse DNS. works > fine for me. > For me as well. Sometimes it's worth to first read and than write. > Regards, > -Sam. > CU, Arnold -- Arnold Nipper Email: arnold.nipper at de-cix.net Heilbronner Str. 34b Phone: +49 700 NIPPER DE D-76131 Karlsruhe Mobil: +49 172 2650958 Germany Fax: +49 180 505255469743 From eamonn at ripe.net Mon Jan 22 10:01:28 2001 From: eamonn at ripe.net (Eamonn McGuinness) Date: Mon, 22 Jan 2001 10:01:28 +0100 Subject: X-NCC-RegID:es.uni2 In-Reply-To: Your message of Fri, 19 Jan 2001 11:02:47 +0100. <1FB73D3CDA3DD311BC9A00902765123901BB761F@M1CORREO2> References: <1FB73D3CDA3DD311BC9A00902765123901BB761F@M1CORREO2> Message-ID: <200101220901.KAA18894@x15.ripe.net> Hello Carmen, The Local IR working group is an open forum where RIPE policy is discussed and made. If you have any policy questions relating to your Local IR please send them to . This mailbox is specifically for members. We announced this at : http://www.ripe.net/ripe/mail-archives/lir-wg/20000701-20001001/msg00135.html You can view all our internal mailboxes at : http://www.ripe.net/ripencc/about/contact.html We will answer your questions now off-line. Kind regards, Eamonn McGuinness RIPE NCC Hostmaster In message <1FB73D3CDA3DD311BC9A00902765123901BB761F at M1CORREO2>you write: >Hello: >I'm not sure if I can ask the next questions in this mail-box, if It is not >possible my apologise. >I have some questions: >1) When we ask for a group Address assignment, have we to detail how many >objects we are going to create?, or if all the objects have the same netname >is enough with one object? >2) When we ask for some Address assignment and a hostmater send us a mail to >accept this request, > A- We have to create the objects of all this addresses very soon or >we have some time to create the objects? How much time? > B- Can we combine this approved address with other existing >assignments ? >3) About the reverse delegation, we have two objects > domain: 37.62.in-addr.arpa > .... > nserver: m2dnsnet1.net.uni2.es > .... > > domain: 36.62.in-addr.arpa > .... > nserver: m2dnsnet1.net.uni2.es > >With this objects when arrive to RIPE a request reverse delegation of this >address RIPE send to our "nserver: m2dnsnet1.net.uni2.es" this request. >If we create other reverse delegation in RIPE of our addresses for a >customer, for example: > domain: 255.37.62.in-addr.arpa > nserver: "customer_server" > nserver: m2dnsnet1.net.uni2.es >Now when arrive to RIPE a request reverse delegation of this address, >62.37.225.0 - 62.37.225.255 RIPE send to "customer_server" this request, >and the rest of the request of address 62.36.0.0 - 62.37.255.255 are sent >to our "nserver: m2dnsnet1.net.uni2.es". Is correct all this?? > >Thanks in advance >Kind regards >Carmen Mijangos > > > >Carmen Mijangos >UNI2 - Ticnico de Servicios de datos >Direccisn Ticnica >Telifono : +34 912520972 / Msvil: +34 667493879 >e-mail: CMijangosR at uni2.es >http://www.uni2.es From sveta at lucky.net Sun Jan 21 20:08:54 2001 From: sveta at lucky.net (Svetlana Tkachenko) Date: Sun, 21 Jan 2001 21:08:54 +0200 (EET) Subject: URGENT: Database problems? In-Reply-To: from Berislav Todorovic at "Jan 21, 2001 07:48:45 pm" Message-ID: <200101211908.VDL08262@burka.carrier.kiev.ua> I thing something wrong with database itself. Updates for domain objects proceeded without any delay. > Dear RIPE NCC colleagues, > > I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, > but can someone, please, take a look on the database update queue? Either > the queue is full or the automatic email robot is broken. > > We sent an update of AS-KPNQWESTRO few times since Friday and no answer we > got from the robot. That's 3 (three) days !!!!!!!!! > > Thanks! > > Beri > > --------- Berislav Todorovic, Network Engineer --------- > ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- > ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- > --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- > -- Email: beri at kpnqwest.net <=> beri at EU.net -- > --- _ _ ____ _ .--. ____ ____ __/_ --- > ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- > From ripe-dbm at ripe.net Mon Jan 22 17:55:34 2001 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 22 Jan 2001 17:55:34 +0100 Subject: Delays in RIPE Database updates Message-ID: <200101221655.RAA04945@x51.ripe.net> Dear All, As some of you may have already noted, we are experiencing delays with the processing of updates in the RIPE Database. This is due to the fact that the last week-end, the reindexing of person objects took much longer than expected; in the meanwhile, no updates could be processed, so they remained blocked in the queue. As of now, the updates are being regularly processed. We want to stress the fact that your updates will be eventually processed and there is no need to resend your update messages; this will have the sole effect of adding load to the update queue. To check the current wait time for updates and other operational statistics for the RIPE Whois Database server, please see: http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html We apologize for any inconvenience this may cause or have caused. If you have any questions, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration. From hph at online.no Tue Jan 23 15:30:30 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 23 Jan 2001 15:30:30 +0100 (CET) Subject: Draft agenda lir-wg: regional issues Message-ID: <8104563.980260230807.JavaMail.webmail1@wm-java1.fg.online.no> Dear lir-wg, here is a draft agenda for tomorrows meeting. My sincere appologies for this late submission. A draft agenda for todays lir-wg global issues will follow shortly. Note that some of the issues have status pending due to lack of confirmation from the speakers. Note also that I have put the issue "management of the working group on the agenda." Here you will have the oportunity to suggest improvements to the running of this wg. Do not forget this is your forum to set and change policy ! Sincerely, Hans Petter Holen 1 Admin - scribe, participant list, charter, mailing-lists 2 Agenda - moved reports top plenary only 3 RIPE 37 minutes & actions 4 Report from the RIPE NCC Hostmasters by Nurani Nimpuno incl. Meet the hostmasters 5 Discussion on service level improvements, 17th of may task force 6 Management of working group x-X-x Break x?X-x 7 IPv4 address exhaustion, by Tony Holmes and Paul Mylotte 8 Ip addressing for mobile handsets (to be confirmed) 9 Provider Independent addresses (to be confirmed) 10 36.5 Assignment window applied on infrastructure (to be confirmed) 11 36.7 Transfer of pre RIR address space to LIR 12 Preparing the plenary AC election: candidates, proceudres 13 PGP Key Exchange (to be confirmed) 14 Restoring the transparency (continued, to be confirmed) EOM From hph at online.no Tue Jan 23 15:42:32 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 23 Jan 2001 15:42:32 +0100 (CET) Subject: Draft agenda lir-wg: global issues In-Reply-To: <8104563.980260230807.JavaMail.webmail1@wm-java1.fg.online.no> Message-ID: <28888287.980260952823.JavaMail.webmail1@wm-java1.fg.online.no> Here comes a draft agenda for todays lir-wg meeting on global policy issues: 1 ASO AC Update 2 ASO Goals 2001 ? what should they be 3 ASO OPEN General Meeting 4 AC phone conferences 5 ... 6 ... From hph at online.no Wed Jan 24 09:08:57 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 24 Jan 2001 09:08:57 +0100 (CET) Subject: Draft agenda lir-wg: regional issues In-Reply-To: <8104563.980260230807.JavaMail.webmail1@wm-java1.fg.online.no> Message-ID: <298631.980323737493.JavaMail.webmail2@wm-java4.fg.online.no> Here is Draft 2.0 of the agenda: Admin - scribe, participant list, charter, mailing-lists Agenda RIPE 37 minutes & actions Management of working group Report from the RIPE NCC Hostmasters by Nurani Nimpuno The IP address request form, Joao Damas Discussion IPv4 address exhaustion, by Tony Holmes and Paul Mylotte Preparing the plenary AC election: candidates, proceudres Fixed Boundary assignments for end users, Leo Vegoda Provider Independent addresses Andrezej Karpinski 34.6 LIR-ALLOCATED revisited, James Aldridge 36.5 Assignment window applied on infrastructure 36.7 Transfer of pre RIR address space to RIRs From hph at online.no Wed Jan 24 09:41:47 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 24 Jan 2001 09:41:47 +0100 (CET) Subject: Management of the working group Message-ID: <12772179.980325707779.JavaMail.webmail2@wm-java2.fg.online.no> Dear lir-wg, as just expressed at the wg meeting, I think it is appropriate to suggest some formalities for the wg to elect its chairs. My proposal is as following: 1) Open nominations on the lir-wg mailinglist 2) Optional discussion and support statements 3) Election of chair and 1-2 co chairs at the next lir-wg meeting in Bologna. 3b) The election to be performed either open ballot or by secret ballot if demanded by one or more participants at the meeting 3c) The election to be confirmed by consensus by the wg after the election result have been duly counted by a counting team from the audience. 4) That we perform such an election annualy to ensure the community support to the wg chairs. As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. Sincerely, Hans Petter Holen lir-wg Chair From Frode.Greisen at ebone.net Wed Jan 24 13:59:23 2001 From: Frode.Greisen at ebone.net (Frode Greisen) Date: Wed, 24 Jan 2001 12:59:23 +0000 (GMT Standard Time) Subject: Management of the working group In-Reply-To: <12772179.980325707779.JavaMail.webmail2@wm-java2.fg.online.no> Message-ID: Hi Hans Petter, generally looks like a very good scheme to me. some detailed remarks below. On Wed, 24 Jan 2001, Hans Petter Holen wrote: > Dear lir-wg, > as just expressed at the wg meeting, I think it is appropriate to > suggest some formalities for the wg to elect its chairs. > > My proposal is as following: > > 1) Open nominations on the lir-wg mailinglist > 2) Optional discussion and support statements > > 3) Election of chair and 1-2 co chairs at the next lir-wg > meeting in Bologna. > > 3b) The election to be performed either open ballot or > by secret ballot if demanded by one or more > participants at the meeting. Each LIR has one vote. > > 3c) The election to be confirmed by consensus by the wg > after the election result have been duly counted by a > counting team from the audience. what if there is no consensus?: I suggest the reverse: 3c) The results of the election is sent to the mailing list. If at least 10 LIRs are not satisfied with the outcome, they can state this via email within three weeks and a new election is done at the next meeting. > > 4) That we perform such an election annualy to ensure the > community support to the wg chairs. > > As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. > > Sincerely, > Hans Petter Holen > lir-wg Chair > > best regards/Frode ----------------------------------------------------------------------- Frode Greisen phone: +44 20 7769 8410 Ebone mobile: +44 79 6879 9115 151 Shaftesbury Ave. fax: +44 20 7769 8084 London WC2H 8AL United Kingdom email: frode.greisen at ebone.net ----------------------------------------------------------------------- From Frode.Greisen at ebone.net Wed Jan 24 14:48:16 2001 From: Frode.Greisen at ebone.net (Frode Greisen) Date: Wed, 24 Jan 2001 13:48:16 +0000 (GMT Standard Time) Subject: Management of the working group In-Reply-To: <20010124142459.A4651@NL.UU.NET> Message-ID: OK, I buy the arguments of Neil and Andre. Of course there is always the risk of one company sending a large group and hijacking the process which is easier with a formal vote than with rough consensus. But I guess for simplicity it then has to be one person one vote. Frode On Wed, 24 Jan 2001, Andre Koopal wrote: > On Wed, Jan 24, 2001 at 12:59:23PM +0000, Frode Greisen wrote: > > Hi Hans Petter, > > > > generally looks like a very good scheme to me. some detailed remarks > > below. > > > > On Wed, 24 Jan 2001, Hans Petter Holen wrote: > > > > > Dear lir-wg, > > > as just expressed at the wg meeting, I think it is appropriate to > > > suggest some formalities for the wg to elect its chairs. > > > > > > My proposal is as following: > > > > > > 1) Open nominations on the lir-wg mailinglist > > > 2) Optional discussion and support statements > > > > > > 3) Election of chair and 1-2 co chairs at the next lir-wg > > > meeting in Bologna. > > > > > > 3b) The election to be performed either open ballot or > > > by secret ballot if demanded by one or more > > > participants at the meeting. > > Each LIR has one vote. > > This is an open forum, it is not tied to RIPE ncc membership, and it should > also never be ... > > Regards, > > Andre > > > > > > 3c) The election to be confirmed by consensus by the wg > > > after the election result have been duly counted by a > > > counting team from the audience. > > what if there is no consensus?: I suggest the reverse: > > > > 3c) The results of the election is sent to the mailing list. If at least > > 10 LIRs are not satisfied with the outcome, they can state this via email > > within three weeks and a new election is done at the next meeting. > > > > > > > > > > 4) That we perform such an election annualy to ensure the > > > community support to the wg chairs. > > > > > > As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. > > > > > > Sincerely, > > > Hans Petter Holen > > > lir-wg Chair > > > > > > > > > > best regards/Frode > > ----------------------------------------------------------------------- > > Frode Greisen phone: +44 20 7769 8410 > > Ebone mobile: +44 79 6879 9115 > > 151 Shaftesbury Ave. fax: +44 20 7769 8084 > > London WC2H 8AL > > United Kingdom email: frode.greisen at ebone.net > > ----------------------------------------------------------------------- > From neil at COLT.NET Wed Jan 24 14:23:38 2001 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 24 Jan 2001 13:23:38 -0000 Subject: Management of the working group In-Reply-To: Message-ID: > Each LIR has one vote. This needs to be limited so that one company with multiple LIR's don't have a way to sway the vote. [COLT has 12 LIR's as an example]. Neil. From andre at NL.UU.NET Wed Jan 24 14:24:59 2001 From: andre at NL.UU.NET (Andre Koopal) Date: Wed, 24 Jan 2001 14:24:59 +0100 Subject: Management of the working group In-Reply-To: ; from Frode Greisen on Wed, Jan 24, 2001 at 12:59:23PM +0000 References: <12772179.980325707779.JavaMail.webmail2@wm-java2.fg.online.no> Message-ID: <20010124142459.A4651@NL.UU.NET> On Wed, Jan 24, 2001 at 12:59:23PM +0000, Frode Greisen wrote: > Hi Hans Petter, > > generally looks like a very good scheme to me. some detailed remarks > below. > > On Wed, 24 Jan 2001, Hans Petter Holen wrote: > > > Dear lir-wg, > > as just expressed at the wg meeting, I think it is appropriate to > > suggest some formalities for the wg to elect its chairs. > > > > My proposal is as following: > > > > 1) Open nominations on the lir-wg mailinglist > > 2) Optional discussion and support statements > > > > 3) Election of chair and 1-2 co chairs at the next lir-wg > > meeting in Bologna. > > > > 3b) The election to be performed either open ballot or > > by secret ballot if demanded by one or more > > participants at the meeting. > Each LIR has one vote. This is an open forum, it is not tied to RIPE ncc membership, and it should also never be ... Regards, Andre > > > > 3c) The election to be confirmed by consensus by the wg > > after the election result have been duly counted by a > > counting team from the audience. > what if there is no consensus?: I suggest the reverse: > > 3c) The results of the election is sent to the mailing list. If at least > 10 LIRs are not satisfied with the outcome, they can state this via email > within three weeks and a new election is done at the next meeting. > > > > > > 4) That we perform such an election annualy to ensure the > > community support to the wg chairs. > > > > As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. > > > > Sincerely, > > Hans Petter Holen > > lir-wg Chair > > > > > > best regards/Frode > ----------------------------------------------------------------------- > Frode Greisen phone: +44 20 7769 8410 > Ebone mobile: +44 79 6879 9115 > 151 Shaftesbury Ave. fax: +44 20 7769 8084 > London WC2H 8AL > United Kingdom email: frode.greisen at ebone.net > ----------------------------------------------------------------------- From rward at above.net Wed Jan 24 15:31:27 2001 From: rward at above.net (Robert Ward) Date: Wed, 24 Jan 2001 14:31:27 -0000 Subject: Management of the working group In-Reply-To: Message-ID: <002a01c08612$56b1cc80$03fea8c0@lonlt0027> Agree exactly. We have several also around Europe. robert -----Original Message----- From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On Behalf Of Neil J. McRae Sent: Wednesday, January 24, 2001 1:24 PM To: Frode Greisen; Hans Petter Holen Cc: lir-wg at ripe.net Subject: RE: Management of the working group > Each LIR has one vote. This needs to be limited so that one company with multiple LIR's don't have a way to sway the vote. [COLT has 12 LIR's as an example]. Neil. From rward at above.net Wed Jan 24 15:29:39 2001 From: rward at above.net (Robert Ward) Date: Wed, 24 Jan 2001 14:29:39 -0000 Subject: Management of the working group In-Reply-To: Message-ID: <002901c08612$16016f60$03fea8c0@lonlt0027> I guess you need to be careful on a per company or group basis as we have several LIR's around Europe but all under the same company. You would not want one person per separate LIR in each country voting on the same issue as the company would probably have the same view. Robert -----Original Message----- From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On Behalf Of Frode Greisen Sent: Wednesday, January 24, 2001 1:48 PM To: Andre Koopal Cc: Hans Petter Holen; lir-wg at ripe.net Subject: Re: Management of the working group OK, I buy the arguments of Neil and Andre. Of course there is always the risk of one company sending a large group and hijacking the process which is easier with a formal vote than with rough consensus. But I guess for simplicity it then has to be one person one vote. Frode On Wed, 24 Jan 2001, Andre Koopal wrote: > On Wed, Jan 24, 2001 at 12:59:23PM +0000, Frode Greisen wrote: > > Hi Hans Petter, > > > > generally looks like a very good scheme to me. some detailed remarks > > below. > > > > On Wed, 24 Jan 2001, Hans Petter Holen wrote: > > > > > Dear lir-wg, > > > as just expressed at the wg meeting, I think it is appropriate to > > > suggest some formalities for the wg to elect its chairs. > > > > > > My proposal is as following: > > > > > > 1) Open nominations on the lir-wg mailinglist > > > 2) Optional discussion and support statements > > > > > > 3) Election of chair and 1-2 co chairs at the next lir-wg > > > meeting in Bologna. > > > > > > 3b) The election to be performed either open ballot or > > > by secret ballot if demanded by one or more > > > participants at the meeting. > > Each LIR has one vote. > > This is an open forum, it is not tied to RIPE ncc membership, and it should > also never be ... > > Regards, > > Andre > > > > > > 3c) The election to be confirmed by consensus by the wg > > > after the election result have been duly counted by a > > > counting team from the audience. > > what if there is no consensus?: I suggest the reverse: > > > > 3c) The results of the election is sent to the mailing list. If at least > > 10 LIRs are not satisfied with the outcome, they can state this via email > > within three weeks and a new election is done at the next meeting. > > > > > > > > > > 4) That we perform such an election annualy to ensure the > > > community support to the wg chairs. > > > > > > As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. > > > > > > Sincerely, > > > Hans Petter Holen > > > lir-wg Chair > > > > > > > > > > best regards/Frode > > ----------------------------------------------------------------------- > > Frode Greisen phone: +44 20 7769 8410 > > Ebone mobile: +44 79 6879 9115 > > 151 Shaftesbury Ave. fax: +44 20 7769 8084 > > London WC2H 8AL > > United Kingdom email: frode.greisen at ebone.net > > ----------------------------------------------------------------------- >