From guy at sirius-cybernetics-corporation.com Mon Apr 2 11:53:37 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 2 Apr 2001 10:53:37 +0100 Subject: lir-wg@ripe.net Message-ID: <20010402105337.A30121@sirius-cybernetics-corporation.com> Hi everyone, This is just a reminder that this is the last day to send in your additional requirements, for those of you not happy with Maldwyn's basic list was last Friday. (If anyone is really desparate to comment, we can extend it, but I get the impression that nobody is). Today, we begin the writing an initial version of the technical specs. Please email in with your speciication suggestions. Maldwyn and I both look forward to commenting. For the moment, let me suggest that the language of Choice should be Perl 5.6 or greater for the backend. I also believe that with regard to a GUI, the web would be the logical bridge between you Windows and you UNIX people. I am thinking that where possible, multi-browser JavaScript should be used to reduced server-side work. I think tha an adaptation of the IP libraries made available by Manuel should be used. Comments? ATB, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From andrei at ripe.net Mon Apr 2 13:28:22 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 02 Apr 2001 13:28:22 +0200 Subject: Plan of the migration to the new RIPE Database Message-ID: <3AC86256.6896AAED@ripe.net> Dear Colleagues, [apologies for duplicate messages] Please find below a list of milestones related to the migration to the new version of the RIPE Database. Your comments and suggestions are welcome. Should you have any further question regarding the migration, please don't hesitate to contact me. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC ------------------------------------------------------------------ Date Actions ------------------------------------------------------------------ 4.04 Final release of the v3.0 DB software 12.04 Advised mirror's switchover to rpsl.ripe.net. - Reminder is sent to NRTM clients on 9.04 - Starting from this date NRTM clients that mirror the RIPE Database are advised to use the new server at rpsl.ripe.net, port 4444 for mirroring. 17-18.04 Migration of the TEST database to v3.0 (RPSL) - TEST Database becomes a RPSL database. Updates are accepted in RPSL format at . - No RIPE-181 TEST database exists anymore. - Estimated downtime 6 hours. 22.04-23.04 Migration of the RIPE Database to v3.0 (RPSL) - New server becomes the official RIPE Database server at 00:00 23.04. - Updates received after 16:00, 22.04 are queued until the new server becomes operational. After that they are automatically converted to RPSL and processed by the new server. New syntax and authorization rules apply. - Downtime in queries will be deliberately introduced to mark the migration. Whois server downtime is planned from 18:00, 22.04 till 00:00 23.04. During this time a message explaining the migration process will be sent as a whois query reply. 23.04, 00:00 New server becomes the official RIPE Database server - Short (1-2 min) downtime is possible during final tests. 23.04, 02:00 New server starts processing updates - Two mail robots are available: - updates in RIPE-181 format (restrictions apply) - updates in RPSL format (recommended). From andrei at ripe.net Mon Apr 2 15:28:04 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 02 Apr 2001 15:28:04 +0200 Subject: Plan of the migration to the new RIPE Database References: <3AC86256.6896AAED@ripe.net> <20010402123312.A27033@whit.ja.net> Message-ID: <3AC87E64.DD64B1AB@ripe.net> Hi Rob, Rob Evans wrote: > > Hi Andrei, > > > Please find below a list of milestones related to the migration to the new > > version of the RIPE Database. > > Silly question; are the times UTC or CET? Sorry about this, all times are CEST (Central European Summer Time, UTC+2). > > Thanks, > Rob Regards, Andrei From guy at sirius-cybernetics-corporation.com Mon Apr 2 18:01:20 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 2 Apr 2001 17:01:20 +0100 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <3946.985274717@ripe.net>; from maldwyn@ripe.net on Thu, Mar 22, 2001 at 04:25:17PM +0100 References: <3946.985274717@ripe.net> Message-ID: <20010402170119.A70339@sirius-cybernetics-corporation.com> These are my $0.02 on the IMPT specs: > General functionality: > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. I think that data should be stored either in a relational database back end or a CVS flat plaintext file, both of which are accessible to the DBI. > These actions must be undoable where necessary. I think that the software should keep a change log for every action performed, recording the user that performed it, the time stamp and a complete description of what change was actioned. This is so that roll back can take place, ie undoable. > Basic validity checks will be performed on all input. We can't add 275.441.45.2/-33 so we better make sure we don't. Equally, having added 10.0.0.0/24 once, adding it again would be a bad thing. Check for these conditions specifically. Can anyone else think of any others to check for? > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. Ditto. > Basic validity checks will be performed on all input. I'd add that with assignments, we should check not to exceed the assignment window as well. > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. I think an online set of forms that can be used in the majority of web browsers would be the best way to approach this. We will need to define and refine the data structures observable to the hostmaster. By this I mean, will he see a range divided up into free space and used space? Will he see pools inside ranges, pigeonholing space for infrastructure, colo, customer dialup etc. Once we have a clearer picture of this, we can go and dicuss an interface, but we need to know what the interface is for before we can design it. I would say that I think that JavaScript is a good idea for saving state, sanitizing input, dredging through entries and make the interface pretty. We will have to be careful as lots of nasty MS extensions are unavailable to other browers. We don't need anything overwhelmingly complex, we do need something that Netscape, Konqueror, Oprah etc can use. > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. We need to define just how much we can automatize sending an receiving emails. I imagine sending; a lot since RIPE NCC already provide robots for quite a lot of stuff already. Receiving emails and parsing human language is beyond that scope of _my_ perl skills, so if anybody is up for the challenge, by all means. I think though, that interpreting what the hostmaster posted back to you is going to be about the level of searching with a reg exp for a ticket number and then flagging the attention the hostmaster to deal with it. > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. I think that using sendmail or exim to open up a mail and send the contents to a ripe recipient should be easy enough. We will need to decide how much automagic stuff should be done by the various scripts. Should the script say "Hey, Hostmaster, you're over 80%. Here, fill out this form and request some more - I'll even post it for you" or should it say "Hey, hostmaster, I noticed we were low on space, last Tuesday and I took the liberty of requesting some more for Frankfurt, and you can now use this new /18 which I just added". > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. Since it has to speak to UNIX and other operating systems (some of you might even be using BeOS) I think that a browser is the most sensible place for a GUI. > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. But infact harder to write something that works on UNIX and Win32. (Although whoever will be running Perl on Windows will no doubt have his work cut out anyhow). A browser is normally more convenient for the user than an Xterm and I for one do not want to be playing around with ncurses. ######## A few other points: IP library? I think Manuels is probably fine. The one I wrote is also fine for IPv4 but I think that Manuel is way ahead of me on the IPv6 front. DBI? I would say its a good place to start. User authentication? I would say that any regular databse would be able to do it fairly easily itself, buit we have a problem with someone wanting to use a CSV file. > The RIPE NCC only accepts requests for new IPv4 Assignments and > Allocations via email to hostmaster at ripe.net and replies only via > email [4]. This should not present too much of a difficulty. > IPV4 Assignment requests must be in RIPE 141 format [5]. > Requests for new IPV4 Allocations have no special format. Again, if we are talking about 141s and such, the NCC have already built a robot for us a jury rig into the new project. > LIRHostmasters handle customer requests for Assignments via telephone, > email and web pages. Any sufficiently well defined interface / form, should make adding a customer assignment little work. > IPMT must have access to the RIPE DB [6] or a local mirror thereof. Using whois and piping the results through a set of regular expressions has worked for me in the past. It is not fast, but it works. Please comment and help refine this into something people are queueing up to help develop! Thanks everyone who is taking an interest. ATB, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From hcb at clark.net Mon Apr 2 18:49:16 2001 From: hcb at clark.net (Howard C. Berkowitz) Date: Mon, 2 Apr 2001 12:49:16 -0400 Subject: lir-wg@ripe.net In-Reply-To: <20010402105337.A30121@sirius-cybernetics-corporation.com> References: <20010402105337.A30121@sirius-cybernetics-corporation.com> Message-ID: >Hi everyone, > >This is just a reminder that this is the >last day to send in your additional requirements, >for those of you not happy with Maldwyn's basic list >was last Friday. Not sure if these are useful or not, but consider, but some resources in which I discussed address management requirements: http://www.nanog.org/mtg-9811/ppt/berk/index.htm http://www.arin.net/minutes/ARIN199910/index.htm The latter presentation complemented Richard Jimmerson's presentation on the templates proper: http://www.arin.net/minutes/tutorial/index.htm While some of the tools described certainly do not deal with the LIR to RIR relationship, they do apply to the LIR to the LIR's customer. Also in managing the customer relationship, see the router renumbering guide, http://www.isi.edu/in-notes/rfc2072.txt From andrei at ripe.net Tue Apr 3 11:04:24 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 03 Apr 2001 11:04:24 +0200 Subject: Another issue related to the migration References: Message-ID: <3AC99218.2B159D10@ripe.net> Dear Colleagues, "Lu, Ping" wrote: > > Andrei, > The existing ripe2rpsl tool will automatically translate "AS-" to "ASN-" > for the aut-num object and I think "ASN-" is more meaningful than "AS_". > If nobody objects against Ping's proposal, let's convert them to "ASN-". I agree that "_" is a bit uncommon. Regards, Andrei > Best Regards. > > Ping Lu > Cable & Wireless Global > Network Tools and Analysis Group, USA > W: +1-703-292-2359 > E: plu at cw.net > > > -----Original Message----- > > From: Andrei Robachevsky [mailto:andrei at ripe.net] > > Sent: Thursday, March 29, 2001 11:10 AM > > To: db-wg at ripe.net; routing-wg at ripe.net; Migration TF; lir-wg at ripe.net > > Subject: Another issue related to the migration > > > > > > Dear Colleagues, > > > > [Apologies for duplicate messages] > > > > One issue related to RIPE-181 to RPSL migration escaped our > > attention and has > > not been discussed. It is related to reserved prefixes that > > cannot appear in > > object names according to RPSL specification (RFC2622) which says: > > > > "Names starting with certain prefixes are reserved for > > certain object types. > > Names starting with "as-" are reserved for as set names. > > Names starting with > > "rs-" are reserved for route set names. Names starting with > > "rtrs-" are > > reserved for router set names. Names starting with "fltr-" > > are reserved for > > filter set names. Names starting with "prng-" are reserved > > for peering set > > names." > > > > Unfortunately "as-name:" attribute is an object name in RPSL > > and we have 133 > > aut-num objects with as-name starting with reserved 'AS-' prefix. > > > > Our suggestion how to deal with these objects is: > > > > 1. Send a message to the maintainers of these objects asking > > them to change the > > name to avoid conflict with RPSL specification. > > 2. Give two-week notice period after which ripe-dbm will > > convert non compliant > > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > > > This is more a "cosmetic" change as as-name is not even a > > lookup key in the RIPE > > Database. > > > > Your comments and suggestions are appreciated. > > > > Best regards, > > > > > > Andrei Robachevsky > > DB Group Manager > > RIPE NCC > > -- Andrei Robachevsky DB Group Manager RIPE NCC From guy at sirius-cybernetics-corporation.com Tue Apr 3 12:00:59 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Tue, 3 Apr 2001 11:00:59 +0100 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010402235044.B5559@xlink.net>; from mlelstv@xlink.net on Mon, Apr 02, 2001 at 11:50:44PM +0200 References: <3946.985274717@ripe.net> <20010402170119.A70339@sirius-cybernetics-corporation.com> <20010402235044.B5559@xlink.net> Message-ID: <20010403110059.A56522@sirius-cybernetics-corporation.com> > Our internal solution does: > > -> assigns subnets out of internal 'allocations' to help aggregation. > The LIR allocations and internal 'allocations' form a tree down to > the most specific assignments. I think that this comes under designing the human viewable data structures to store information about the IP address space itself. I think what you have done is a good idea, though. As Nigel Titley pointed this out to me originally, IP lends itself very nicely to a binary tree of largest free blocks. Lets design the data structure available to the hostmaster. > -> validation against 'overlapping' assignments and assignments out > of 'less specific' allocation bounds. We definately need overlap detection. > -> 'allocation pools' for flexible assignments in cases where addresses > for a single site are not aggregated into a single block. This comes under designing the data structures, I think. > -> searching of unassigned space using a combined exact-fit/first-fit > strategy. Please expand on this. I don't want an end product that decides for you which subnet you will be assigning. That will be useful for people who need to migrate already used ranges of IP address space into the tool (ie everyone). QIP 4 does this, which is another reason why IMHO, it's totally useless. (My views do not represent anybody that Lucent can sue). > -> heuristic net_name generation I think that this is a lovely touch, but it doesn't come into the "minimal requirements" umbrella. > -> quick overview of allocation tree, also showing unassigned gaps. think that this will indeed be a useful feature of any data structre we decide on. > -> data is stored in a database that also stores routing and reverse > DNS information. I don't believe if IPMT is mandated to deal with DNS at all, at least in its first incarnation. > no support for IPv6 so far... IPv6 is something I'd like IPMT to eventually support. Still, this might have to get stuck on the back burner for the moment... So; A summary so far: 1) We need to check for properly formulated dotted quad format IPs: n.n.n.n/m where n >= 0; n <= 255; m >= 1; m <= 32; 2) We need to check for overlaps so that two subnets cannot overlap any space. We need to check for: (where a is frist IP in range, z is last IP in range) 0 : No overlap a1---z1 a2---z2 a1---z1 a2---z2 1 : Range 1 totally inside range 2 a1---z1 a2--------------z2 2 : Range 2 totally inside range 1 a1--------------z1 a2---z2 3 : Partial overlap a1-----z1 a2-----z2 a1-----z1 a2-----z2 4 : Perfect overlap, range 1 == range 2 a1-----z1 a2-----z2 5 : Edge overlap = someone screwed up, editing by hand a1---z1 a2---z2 a1---z1 a2---z2 ie. 10.15.20.0 -- 10.15.21.0 10.15.21.0 -- 10.15.21.255 (oops). 3) We need some kind of data structure to be defined, so that the hostmaster can access the IP space in a sensible way. I reckon this should include: o A way of seeing the IP space - what is free, what is used. o A way of dividing the IP space into sections for assigning to different areas, such as colo, dialup etc. o A sensible method of assigning free space (ie not always the next free block - think of migration). 4) We need to think about IPv6 I hope people will comment on this summary and pummel beat it into shape. Nothing worthwhile ever happened by people being polite. Thank you very much Michael for your comments. Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From kevin.bates at bt.com Tue Apr 3 13:02:23 2001 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Tue, 3 Apr 2001 12:02:23 +0100 Subject: IP Management Tool - Minimum Requirements Message-ID: A couple of additional thoughts - (apologies if they have already come up (i have not been listening properly) ability to import/export data i.e. CSV files possible check for existing netname and/or descr field in assignment ( to prevent exceeding assignment window) delete upon return of assignment - with a check of size etc ability to aggregate two adjacent blocks into one (e.g. an additional assignment is made to an existing user) kevin bates > > Our internal solution does: . . stuff deleted . . . > > > So; A summary so far: > > > 1) We need to check for properly formulated dotted > quad format IPs: > > n.n.n.n/m where n >= 0; > n <= 255; > m >= 1; > m <= 32; > > 2) We need to check for overlaps so that two subnets > cannot overlap any space. > > We need to check for: > (where a is frist IP in range, > z is last IP in range) > > > 0 : No overlap > > a1---z1 > a2---z2 > > a1---z1 > a2---z2 > > 1 : Range 1 totally inside range 2 > > a1---z1 > a2--------------z2 > > 2 : Range 2 totally inside range 1 > > a1--------------z1 > a2---z2 > > 3 : Partial overlap > > a1-----z1 > a2-----z2 > > a1-----z1 > a2-----z2 > > 4 : Perfect overlap, range 1 == range 2 > > a1-----z1 > a2-----z2 > > 5 : Edge overlap = someone screwed up, editing > by hand > > a1---z1 > a2---z2 > > a1---z1 > a2---z2 > > ie. 10.15.20.0 -- 10.15.21.0 > > 10.15.21.0 -- 10.15.21.255 > > (oops). > > 3) We need some kind of data structure to be defined, > so that the hostmaster can access the IP space in a > sensible way. > > I reckon this should include: > > o A way of seeing the IP space - what is free, > what is used. > o A way of dividing the IP space into sections > for assigning to different areas, such as > colo, dialup etc. > o A sensible method of assigning free space (ie > not always the next free block - think of > migration). > > 4) We need to think about IPv6 > > > I hope people will comment on this summary and pummel > beat it into shape. > > Nothing worthwhile ever happened by people being > polite. > > Thank you very much Michael for your comments. > > Guy > > -- > Guy Vegoda \ guy at vegoda.org *Please do not send html* > NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* > Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) > www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From jhma at KPNQwest.net Wed Apr 4 10:18:08 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Wed, 04 Apr 2001 10:18:08 +0200 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: Your message of "Thu, 29 Mar 2001 01:46:24 +0200." <004f01c0b7e1$4f9085d0$0500000a@hph> Message-ID: <200104040818.KAA11613@aegir.EU.net> "Hans Petter Holen" wrote: > I hereby call for nominations to wg-chair and co-chairs. > > Please nominate yourself to lir-wg at ripe.net. It has been suggested that I might like to act as a lir-wg co-chair. I am prepared to put myself forward for that role. Regards, James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL GSM: +31 653 708 707 From nigel.titley at goneto.net Wed Apr 4 12:19:21 2001 From: nigel.titley at goneto.net (Nigel Titley) Date: Wed, 04 Apr 2001 11:19:21 +0100 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: Message from James Aldridge of "Wed, 04 Apr 2001 10:18:08 +0200." <200104040818.KAA11613@aegir.EU.net> References: <200104040818.KAA11613@aegir.EU.net> Message-ID: > "Hans Petter Holen" wrote: > > I hereby call for nominations to wg-chair and co-chairs. > > > > Please nominate yourself to lir-wg at ripe.net. > > It has been suggested that I might like to act as a lir-wg co-chair. I am > prepared to put myself forward for that role. In which case I'll nominate (or second) you Nigel From mike.norris at heanet.ie Wed Apr 4 13:09:10 2001 From: mike.norris at heanet.ie (mike.norris at heanet.ie) Date: Wed, 4 Apr 2001 12:09:10 +0100 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: <3F2D1A940FB8D1118A1F0060978361295EBFAF@ntserver.heanet.ie> Message-ID: <3F2D1A940FB8D1118A1F0060978361295D6BC6@ntserver.heanet.ie> James> > It has been suggested that I might like to act as a lir-wg co-chair. I am James> > prepared to put myself forward for that role. Nigel> In which case I'll nominate (or second) you ... and I'll second (or nominate) you. Mike From darren.taylor at level3.com Wed Apr 4 19:37:45 2001 From: darren.taylor at level3.com (Darren Taylor) Date: Wed, 4 Apr 2001 18:37:45 +0100 Subject: Call for nominations for lir-wg chair and co-chairs Message-ID: <01040418430108.17281@rimmer> "Hans Petter Holen" wrote: > I hereby call for nominations to wg-chair and co-chairs. > > Please nominate yourself to lir-wg at ripe.net. I would like to nominate Denesh Bhabuta for lir-wg co-chair. Darren -- Darren Taylor - IP Address Coordinator darren.taylor at level3.com Level (3) Communications, 66 Prescot Street, London, E1 8HG, UK. Telephone: +44 (0)20 7961 8707 Mobile: +44 (0)77 7624 0660. From hph at online.no Wed Apr 4 20:42:22 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 4 Apr 2001 20:42:22 +0200 Subject: Discussion on change to policy process Message-ID: <03c201c0bd36$fd4735c0$6c35d640@hph> Dear WG, I would like to start a discussion on slightly improving the process for setting new policy. http://www.ripe.net/ripe/wg/lir/howto_devolep.html This is inspired by the ARIN policy process: http://www.arin.net/announcements/policy_eval_process.html Altough this is very different from how we do things in the lir-wg there is one change I would like us to discuss: "To be considered for presentation at these meetings the proposal should be submitted to ARIN staff six (6) weeks prior to commencement of the meetings to allow time for it to be posted and an announcement to be sent out at least thirty (30) days before the meetings convene." Should we in our procedures include a requirement for the proposed change to be submitted to the lir-wg some weeks before the lir-wg meeting ? Hans Petter From mir at ripe.net Wed Apr 4 22:14:23 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 04 Apr 2001 22:14:23 +0200 Subject: RIR Policy Comparison Message-ID: <200104042014.WAA17693@kantoor.ripe.net> Dear all, APNIC, ARIN, and RIPE NCC have co-ordinated to produce the first draft of the RIR Comparative Policy Overview document. The goal of this document is to provide a comparative overview of the policies in the RIR system. It is not a policy statement by the RIRs, but is intended to serve as a reference for the Internet community. This is a public document that will be reviewed and revised through the co-ordinated effort of the RIRs. This document is available at: http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.ht ml Kind Regards, Mirjam Kuehne RIPE NCC From markd at demon.net Wed Apr 4 19:51:23 2001 From: markd at demon.net (Mark Dranse) Date: Wed, 4 Apr 2001 18:51:23 +0100 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: <01040418430108.17281@rimmer>; from darren.taylor@level3.com on Wed, Apr 04, 2001 at 06:37:45PM +0100 References: <01040418430108.17281@rimmer> Message-ID: <20010404185123.A21499@demon.net> Darren Taylor (darren.taylor at level3.com) remarked : > I would like to nominate Denesh Bhabuta for lir-wg co-chair. I'd be delighted to second Denesh. -- Mark Dranse Hostmaster Manager, Operations markd at demon.net Thus Plc / Demon 322 Regents Park Road, Finchley, London N3 2QQ, England Tel: +44 (20) 8371 1181 mbl: +44 (0) 7967 381 554 Fax: +44 (20) 8371 4081 Herengracht 433, 1017 BR, Amsterdam, Netherlands (020-4222-000) From Andreas.Roehling at lambdanet.net Thu Apr 5 09:21:01 2001 From: Andreas.Roehling at lambdanet.net (Roehling, Andreas) Date: Thu, 5 Apr 2001 09:21:01 +0200 Subject: AW: Call for nominations for lir-wg chair and co-chairs Message-ID: <39F27E3F569FD4119EF200508BAF85B9B512BD@CCGNT30> Denesh lasts a good election. Denesh for president. > -----Ursprungliche Nachricht----- > Von: Mark Dranse [mailto:markd at demon.net] > Gesendet: Mittwoch, 4. April 2001 19:51 > An: lir-wg at ripe.net > Betreff: Re: Call for nominations for lir-wg chair and co-chairs > > > Darren Taylor (darren.taylor at level3.com) remarked : > > I would like to nominate Denesh Bhabuta for lir-wg co-chair. > > I'd be delighted to second Denesh. > > -- > Mark Dranse Hostmaster Manager, Operations > markd at demon.net > Thus Plc / Demon 322 Regents Park Road, Finchley, London N3 > 2QQ, England > Tel: +44 (20) 8371 1181 mbl: +44 (0) 7967 381 554 Fax: +44 > (20) 8371 4081 > Herengracht 433, 1017 BR, Amsterdam, Netherlands (020-4222-000) > From ripe-ml at cyberstrider.net Thu Apr 5 11:12:27 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Thu, 05 Apr 2001 10:12:27 +0100 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: <01040418430108.17281@rimmer> Message-ID: <5.0.2.1.2.20010405101142.03f6d6c8@mail.own.cyberstrider.net> At 18:37 04/04/2001, you wrote: >I would like to nominate Denesh Bhabuta for lir-wg co-chair. I accept being Nominated. Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From Patricia.Taylor at Level3.com Thu Apr 5 12:13:31 2001 From: Patricia.Taylor at Level3.com (Taylor, Patricia) Date: Thu, 5 Apr 2001 11:13:31 +0100 Subject: FW: [xdhm] Re: Call for nominations for lir-wg chair and co-chair s Message-ID: <57D22A676F18D511A8570002A52C8B060770CC@N0506LON2> I would like to second Denesh Bhabuta for lir-wg co-chair. regards Trish Taylor-Dolan Level3 Communications "Hans Petter Holen" wrote: > I hereby call for nominations to wg-chair and co-chairs. > > Please nominate yourself to lir-wg at ripe.net. I would like to nominate Denesh Bhabuta for lir-wg co-chair. Darren -- From db-news at ripe.net Thu Apr 5 13:53:09 2001 From: db-news at ripe.net (DB-News) Date: Thu, 05 Apr 2001 13:53:09 +0200 Subject: RIPE Database Software Version 3.0. Message-ID: <200104051153.NAA28604@office.ripe.net> Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0 of the RIPE Database software. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). You can download this release by anonymous ftp from the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0.tar.gz We remind you that you can also test the functionality of this release of the new RIPE Whois server in 2 ways: - by querying the host rpsl.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database; this mirror is in RPSL format; - by using the RIP Test Database; you can send test updates to this database at the address , and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test this release in both ways, and send us your comments. Comments and bug reports may be sent to the mailing list. To subscribe to this list, send a message to with the line: subscribe db-beta in the body of your message. This is a moderated mailing list so some delays in subscription are possible. Version 3 of the RIPE Database software will be deployed on the RIPE Whois server on 23 April 2001. Please see http://www.ripe.net/rpsl/ for more information on how this will affect you. There is a mailing list to discuss the migration to the new service, . To subscribe, send a message to with the line: subscribe reimp-mig-tf in the body of your message. As for the db-beta mailing list, this is a moderated mailing list so some delays and so some delays in subscription are possible. If you have any other questions or comments, please contact . Regards, A. M. R. Magee ______________ RIPE NCC From zsako at banknet.net Thu Apr 5 16:42:50 2001 From: zsako at banknet.net (Janos Zsako) Date: Thu, 5 Apr 2001 16:42:50 +0200 (MET DST) Subject: Call for nominations for lir-wg chair and co-chairs Message-ID: <200104051442.QAA24808@banknet.banknet.net> > From owner-lir-wg at ripe.net Thu Mar 29 01:11:49 2001 Dear colleagues, > Please nominate yourself to lir-wg at ripe.net. I was suggested to nominate myself as a co-chair. I am prepared to be a candidate for this role. Best regards, Janos Zsako (JZ38) From mike.norris at heanet.ie Thu Apr 5 17:38:34 2001 From: mike.norris at heanet.ie (mike.norris at heanet.ie) Date: Thu, 5 Apr 2001 16:38:34 +0100 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: <3F2D1A940FB8D1118A1F0060978361295F135D@ntserver.heanet.ie> Message-ID: <3F2D1A940FB8D1118A1F0060978361295EF514@ntserver.heanet.ie> > > Please nominate yourself to lir-wg at ripe.net. > > I was suggested to nominate myself as a co-chair. > > I am prepared to be a candidate for this role. I'll certainly second you, Janos. Mike From Stefan.Gasteiger at Gendorf.de Fri Apr 6 11:58:44 2001 From: Stefan.Gasteiger at Gendorf.de (Stefan.Gasteiger at Gendorf.de) Date: Fri, 6 Apr 2001 11:58:44 +0200 Subject: change maintainer Message-ID: <4185051FE012D411A98B0008C7337A2E01CD1537@ATLANTIS> sorry, if this is trivial or has been asked before. how can i change the mnt-by attribute of an object? i am authoritative for both maintainers. Kind regards, Stefan Gasteiger I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger at gendorf.de From hph at online.no Sat Apr 7 15:14:14 2001 From: hph at online.no (Hans Petter Holen) Date: Sat, 7 Apr 2001 15:14:14 +0200 Subject: ICANN Board Nominations - Expression of support Message-ID: <004f01c0bf64$a4e43d30$0600000a@hph> Dear WG, The address council is about to elect a new Director for the ICANN board over the next few months. The nominees can be found at: http://www.aso.icann.org/board/comf_board_members.html It would be valuable , at least for myself, to get advice from members of this working group on the candidates in question. You may express your support by clicking on the Express support link on the page refered to above. Hans Petter From arif.oktay at telekom.gov.tr Sat Apr 7 17:39:50 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Sat, 7 Apr 2001 18:39:50 +0300 Subject: PI assignments Message-ID: Hi, Can anybody help me about PI assigments please ? I have sent a PI request nearly 2 mounths ago. Though the automatic answer said that it was handed to a hostmaster, I couldn't receive any response since then. I have also send an e-mail to ncc at ripe.net and I couldn't receive any answer yet either. Is there a policy conflict I'm missing ? Regards arif ao189-ripe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-dbm at ripe.net Mon Apr 9 17:39:42 2001 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 09 Apr 2001 17:39:42 +0200 Subject: change maintainer Message-ID: <200104091539.RAA11066@office.ripe.net> Dear Colleagues, We have answered Mr. Gasteiger's question. For any questions regarding the RIPE database, please contact . Regards, A. M. R. Magee ______________ RIPE NCC From mally at ripe.net Tue Apr 10 11:54:57 2001 From: mally at ripe.net (Mally McLane) Date: Tue, 10 Apr 2001 11:54:57 +0200 (CEST) Subject: PI assignments In-Reply-To: Message-ID: Dear Colleagues, We have answered Mr Oktay's question. As a reminder, if you ever need to check the status of one of your open tickets, you can do so using your ticket number, on our website at: http://www.ripe.net/cgi-bin/rttquery Regards, Mally Mclane RIPE NCC Staff From huberman at gblx.net Thu Apr 12 09:01:58 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 12 Apr 2001 00:01:58 -0700 (MST) Subject: Discussion on change to policy process In-Reply-To: <03c201c0bd36$fd4735c0$6c35d640@hph> Message-ID: > Altough this is very different from how we do things in the lir-wg > there is one change I would like us to discuss: > > "To be considered for presentation at these meetings the proposal > should be submitted to ARIN staff six (6) weeks prior to commencement > of the meetings to allow time for it to be posted and an announcement > to be sent out at least thirty (30) days before the meetings convene." This policy appears to work quite effectively in ARIN policy discussions. More pointedly, when such efforts are *not* taken, the membership tends to get quite upset. Mailing lists are one of the few ways for RIPE to open its policy making discussions to all interested parties. As such, all proposed changes to RIPE policies should definitely be posted in lir-wg in advance of their discussion at RIPE meetings. Hans-Petter's policy process change is a good one, in my opinion. /david From Torsten.Blum at ecrc.de Tue Apr 10 14:39:45 2001 From: Torsten.Blum at ecrc.de (Torsten Blum) Date: Tue, 10 Apr 2001 14:39:45 +0200 (CEST) Subject: change maintainer In-Reply-To: <4185051FE012D411A98B0008C7337A2E01CD1537@ATLANTIS> from "Stefan.Gasteiger@Gendorf.de" at "Apr 6, 2001 11:58:44 am" Message-ID: <200104101239.OAA03855@turon.ecrc.de> Stefan.Gasteiger at Gendorf.de wrote: > sorry, if this is trivial or has been asked before. > how can i change the mnt-by attribute of an object? > i am authoritative for both maintainers. Add the new work and update the record. If it was successfull, remove the old one and update the record again. -tb -- Torsten Blum, Network Engineer E-Mail: torstenb@{cw.net,ecrc.de} Cable & Wireless ECRC, Network Engineering Group Tel: +49.89.92699.0 Landsbergerstr. 155, D-81925 Munich, Germany Fax: +49.89.92699.809 From andrei at ripe.net Wed Apr 18 16:06:54 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 18 Apr 2001 16:06:54 +0200 Subject: Migration of the TEST database is delayed Message-ID: <3ADD9F7E.E87DD441@ripe.net> Dear colleagues, Unfortunately due to hardware problems with the computer running TEST database server we need to delay the migration of the TEST database that was planned on 17-18.04. We plan to start the migration of the TEST database tomorrow, 19.04. We will keep you informed. Sorry for any inconvenience this caused. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From david at IPRG.nokia.com Thu Apr 19 04:59:22 2001 From: david at IPRG.nokia.com (David Kessens) Date: Wed, 18 Apr 2001 19:59:22 -0700 Subject: draft agenda (v1) for IPv6 working group RIPE39 Message-ID: <20010418195922.A17357@iprg.nokia.com> Hi, Below follows the first draft of the agenda for the ipv6 wg. The current plan is to use the second part of our session for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Please let me know if you have any other topics that you want to have discussed or if you would like to volunteer for a presentation. We still have some time left in our agenda for additional topics. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg E. Draft on allocation sizes (Niall Murphy) F. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB --- From guy at sirius-cybernetics-corporation.com Thu Apr 19 12:48:29 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Thu, 19 Apr 2001 11:48:29 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] Message-ID: <20010419114829.A62655@sirius-cybernetics-corporation.com> Hi there all you internet people! I hope your all well, I emailed this to everyone yesterday and was dismayed when nobody commented on it. Only this morning did I notice that I mailed it to lir-wg at sirius-cybernetics-corporation.com rather than lir-wg at ripe.net by mistake )-: Hmm. Please enjoy your reading this mail. Thaaaank youuuuu. So here is my considered and very close to final draft of the top down specs for the IMPT program. You are all invited to tear it to peaces in the purpose of constructive whatsit. I would ask, if you are going to point out a problem, at least also point out a solution. ________________________________________________________________________ Questions: 1. Which platforms are we looking to support? I think that UNIX platforms would be easier for development, and would cover the needs of the majority of users. Also, ala Perl. A gui provides windows users with an opportunity to use the sotware too. The same could be achieved on a win32 platform under visual basic, but this would strain the GNU lisence considerable, as well as denying use by the UNIX users amongst us. Miscrosoft have a web platform and we could theortically write the whole thing in ASP. MS's web server is NOT free however, and ASP, in my opinion is less open than Perl. An apache web server is free, and I believe that they even have a windows version. Perl exists for windows. I don't recommend this setup, but I believe that it's better than ASP under a MS web server. Equally, the majority of people would find Perl easy and familiar. Many excellent, free, IP libraries already exist. They are also exstensible. 2. What's up with this IPv6 thing? Since, AFAICT, IPv6 still isn't _finished_ finished, let's leave room for it, but not impliment it yet. When the time comes, and it is polished and ready, we can slot in IPv6 support. > General functionality: > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. Questions: 1. How do we store this information? How about a back end database capable of being acccessed by the DBI for the following reasons: a. If you don't want to run a database, the DBI can be used with a CSV filei. (Beware multiple users about data integrity). b. SQL shouldn't change too much from one DBMS to another, and the DBI code stays the same. c. It's free (the DBI) and talks to free DBMS's like mysql and postgreSQL. 2. In which case, how will data modifications be achieved? We're just talking 'bout plain old SQL here. 3. How will we make updates undoable? a. So, you changed the wrong customer's address by accident and now you need to change it back, but you can't find the original scrap of paper. How do you reverse the change? We're are talking about keeping logs, here, right? It would be simple if every DBMS was the same, but since we cannot rely on that, we need a database independent solution. I recommend a table containing this information, accessible in the same way by the DBI. b. We can embed enough information in the tables store a chronological history of what has happened to a particular and restore previous incarnations. 4. How will be make the software multi user proof? I haven't figured this one out yet. There is a really easy way with MySQL, but that doesn't scale to other DBMS systems. 5. Which checks need be done? I believe the following are crucial: o IP Address Space ranges must not overlap each other. o IP ranges must be entered correctly, or else give error messages. o Non IP information, such as customer names and addresses should be unique. o IP addresses should not be on illegal bit boundaries. o Assignment windows should not be exceeded for any given customer. 6. How should IP ranges be inserted? By this I am asking about the mechanisms for choosing how to assign out of one's allocation. I recommend an auto-manual solution wherby the computer is able to work out exactly which IP ranges matching your criteria are free and assignable, and allign them all nicely along the bit boundaries. The human can then choose out of a list which IP range to assign. The advantages are that you don't have to do too much math yourself, but neither are you stuch when it comes to migrating existing allocations into the program. 7. How much non IP info should be stored in the database, such as customer address, names, contact...? My view is that enough should be stored to be able to autogenerate an intenum object. Remaining problems: 1. With regard to storing both allocation information assignment information, perhaps also, customer information: What kind of data structure will we use? What about people with multiple registries? 2. We still need to tackle the mutli user problem. 3. If assigning something would exceed the window, we need to have some process. Autogenerate a 141? Maybe. If we did, how do we tell the software that the assignment has been approved? Have a toggle? Perhaps, but this need furthere discussion. > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. Questions: 1. What does this mean? It is very general. (I should have spotted this during the reqs stage and primpted for more clarity. My bad.) Does the IMPT program sit on the end of an email address and parse 141 forms? My belief is that IMPT needs to be simple. By all means, have an inetnum autogenerator built into the program as that's easy. As for "allowing the LIRHostmasters to receive requests", I think that this means "Not getting in the way". All companies and organisations have their own policies and protocols for dealing with customers. We need an easy GUI for entering cust info and making assignments. Automise what we can and simplify what we can't. Clearly this needs further discussion WRT details! 2. Process them: ie integrate them into their DB? Do we save customer information accross multiple assignments, or keep a separate customer record for each assignment? I strongly opt for the former. This suggests that a customer object/table in the database would be a GOOD THING (tm). > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. Questions: 1. Which requests should be sent? For assignments, I believe that the following are non negotiable: a. inetnum objects, (whether or not the customer already has a person object- thats's what auto-1 is for.) So how do we tell IMPT when RIPE assigns the person object to a customer? How about hourly reminders so that the human is reminded to reguraly check his/her email and add the contact info when it is ready? b. 141 forms. These can be a right illigitimate child. Cull information from the DB and automate it as much as possible. I believe that any required use of the RIPE Whois is an example of a defincieny in the scope of data stored by the backend DBMS. For allocations, I believe these _are_ negotiable: Requests for more space. It's nice having this automated. However, how easy would it be to program? I've a feeling, letting the hostmaster know that NOW is a good time to get new space might have to do. And most hostsmasters are bright enough to know this themselves. Problems: 1. Basicaly, this needs low level refining. What and how. 2. To what extent do we need to deal with replies from RIPE NCC? Should we attempt to flag the users attention or parse the email itself? Should we extract any ticket numbers? What do we do with them? > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. > > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. I think I discussed most of this at the top. Questions remaining: 1. Java script enabled? My choice would be a cautious yes... Maybe an old Javascript just for keeping state and sanatizing input (performing above checks?), so that most browsers won't choke. 2. Fancy shmancy HTML? I'm no web designer. Not sure how thos would be too much a problem as long as its multi broswer compliant. 3. Cookies? Not, should we use them, but, do we need them? 4. Keeping state otherwise? See, I think we need to get this far. 5. Who will design it so it looks pretty? Who among you does designs thinsg to be easy to use, and to look purdy? ________________________________________________________________________ So, hows about letting me know what y'all think? Thanks, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From niallm-ripe at enigma.ie Thu Apr 19 13:36:06 2001 From: niallm-ripe at enigma.ie (Niall Richard Murphy) Date: Thu, 19 Apr 2001 12:36:06 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419114829.A62655@sirius-cybernetics-corporation.com>; from guy@sirius-cybernetics-corporation.com on Thu, Apr 19, 2001 at 11:48:29AM +0100 References: <20010419114829.A62655@sirius-cybernetics-corporation.com> Message-ID: <20010419123606.B25279@enigma.ie> On Thu, Apr 19, 2001 at 11:48:29AM +0100, Guy Vegoda wrote: I would like PHP as a platform rather than perl. Reasons: 1. It's quite likely to be faster than Perl. 2. It enables people with mod_php but not mod_perl to install IMPT :) 3. It's likely to be easier to do the front-end bits in PHP because of it's built in primitives. Niall > Guy Vegoda \ guy at vegoda.org *Please do not send html* > NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* > Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) > www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ From guy at sirius-cybernetics-corporation.com Thu Apr 19 14:06:20 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Thu, 19 Apr 2001 13:06:20 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419123606.B25279@enigma.ie>; from niallm-ripe@enigma.ie on Thu, Apr 19, 2001 at 12:36:06PM +0100 References: <20010419114829.A62655@sirius-cybernetics-corporation.com> <20010419123606.B25279@enigma.ie> Message-ID: <20010419130620.A66952@sirius-cybernetics-corporation.com> > I would like PHP as a platform rather than perl. > > Reasons: > 1. It's quite likely to be faster than Perl. Will speed be such an issue? Will the back end DBMS not limit the speed quite a lot, too? > 2. It enables people with mod_php but not mod_perl to install IMPT :) I'd not have thought that mod_perl is such a hassle to install. Anyhow, even without it, apache can still run perl programs, and most people already do run it. I think you will find the majority of the users being familiar with Perl already. > 3. It's likely to be easier to do the front-end bits in PHP because of it's > built in primitives. For the front end stuff, we can still use PHP or JavaScript if people are desperate to do so. Easier? No. Faster, prettier, better? Yes, you're right on that score. Front-end aside, It might be be a smart idea to use Perl for the back end, unless you propose an alternative to the DBI. I think it would be interesting to take a straw pole on this issue, anyhow. ATB, Thanks for your comments, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From niallm-ripe at enigma.ie Thu Apr 19 14:23:54 2001 From: niallm-ripe at enigma.ie (Niall Richard Murphy) Date: Thu, 19 Apr 2001 13:23:54 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419130620.A66952@sirius-cybernetics-corporation.com>; from guy@sirius-cybernetics-corporation.com on Thu, Apr 19, 2001 at 01:06:20PM +0100 References: <20010419114829.A62655@sirius-cybernetics-corporation.com> <20010419123606.B25279@enigma.ie> <20010419130620.A66952@sirius-cybernetics-corporation.com> Message-ID: <20010419132354.A94132@enigma.ie> On Thu, Apr 19, 2001 at 01:06:20PM +0100, Guy Vegoda wrote: Hey Guy, > Will the back end DBMS not limit the speed quite a lot, > too? Surely not, especially if a database with a native IP type (for example, Postgres) is used, or an equivalent kludge. > I think you will find the majority of the users being > familiar with Perl already. Yes, as you suggest, some perl is necessary. The question is how much. > Easier? No. Faster, prettier, better? Yes, you're > right on that score. I have worked on a similar program in the past, and the hardest bit of it was getting the front-end code in a manageable and easily extendable/ modifyable state. Even with CPAN libraries the code is quite complex. PHP has the potential to make that a lot easier. > I think it would be interesting to take a straw pole > on this issue, anyhow. Well, I think I can be pretty sure that Perl will win, but that doesn't mean we couldn't save ourselves a lot of effort by being clever. Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ From maldwyn at ripe.net Thu Apr 19 14:19:53 2001 From: maldwyn at ripe.net (Maldwyn Morris) Date: Thu, 19 Apr 2001 14:19:53 +0200 Subject: ANNOUNCEMENT: New Version of Asused Message-ID: <25457.987682793@ripe.net> Hi, The RIPE NCC are pleased to announce the release of a new version of Asused - this is Version 3.60. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.60.tar.gz or alternatively, just: ftp://ftp.ripe.net/tools/asused-latest.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The main change since Version 3.52 is that Whois DB Version 3 objects are now handled correctly. Timur Bakeyev of RIPE NCC did the programming. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to the address below. Cheers, Maldwyn Morris swcontact at ripe.net From guy at sirius-cybernetics-corporation.com Thu Apr 19 17:11:09 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Thu, 19 Apr 2001 16:11:09 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419132354.A94132@enigma.ie>; from niallm-ripe@enigma.ie on Thu, Apr 19, 2001 at 01:23:54PM +0100 References: <20010419114829.A62655@sirius-cybernetics-corporation.com> <20010419123606.B25279@enigma.ie> <20010419130620.A66952@sirius-cybernetics-corporation.com> <20010419132354.A94132@enigma.ie> Message-ID: <20010419161109.G66952@sirius-cybernetics-corporation.com> > Well, I think I can be pretty sure that Perl will win, but that doesn't > mean we couldn't save ourselves a lot of effort by being clever. > > Niall Probably you are right vis a vis front end. However, JavaScript might be equally worth considering. All I'd say - and this is just a suggestion - is that I feel the choice of language will affect who volunteers to help code. I believe that fewer people know PHP, and a smaller developer base might not necessarily be a good thing. Dave Pratt mentioned that he also had some experience with this. That means that both of you have more experience than me because the only front end I have written is based on the standard CGI module, is server based and is about as pretty as a land fill site. I recommend that the two of you hammer away at this together. BTW, please keep the discussions on the lir-wg list; Maldwyn had this to say: > Ps, Dave Pratt's point is a valid one - do you think > it will be worth creating a separate majordomo-list > for the developers of IPMT? I suggest Manuel brings this up in the Tools WG at RIPE 39. I think a developers list should indeed be set up, but that we should not be afraid to post to lir-wg anything that might benefit from a wider audience than the people specifically signed up to be a developer. Specifically, I think the discussions at the current level ( spec ) belong on lir-wg. ATB, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From marck at rinet.ru Thu Apr 19 17:37:20 2001 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu, 19 Apr 2001 19:37:20 +0400 (MSD) Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419123606.B25279@enigma.ie> Message-ID: On Thu, 19 Apr 2001, Niall Richard Murphy wrote: NRM> I would like PHP as a platform rather than perl. NRM> NRM> Reasons: NRM> 1. It's quite likely to be faster than Perl. NRM> 2. It enables people with mod_php but not mod_perl to install IMPT :) NRM> 3. It's likely to be easier to do the front-end bits in PHP because of it's NRM> built in primitives. I'm afraid I vote against PHP. Reasons: - most of current UNIX OSes have Perl5 built-in in default installation; PHP, on the other hand, is additional package - PHP under Win32 as far as I know is significally less stable than Perl - there is no need to install mod_perl to get IMPT workable -- you need mod_perl only for performance improvement under really huge load Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From gyan at nl.demon.net Thu Apr 19 17:44:07 2001 From: gyan at nl.demon.net (Gyan Mathur) Date: Thu, 19 Apr 2001 17:44:07 +0200 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: Message from Guy Vegoda of "Thu, 19 Apr 2001 16:11:09 BST." <20010419161109.G66952@sirius-cybernetics-corporation.com> Message-ID: In response to Guy Vegoda: > However, JavaScript might be equally worth considering. Please don't make something that can only be used with Javascript. In our office, Javascript is considered a security risk and it is not allowed to switch it on on any browser here, so we would be unable to use your tool. Gyan Mathur nl.demon From jasper at ivision.co.uk Thu Apr 19 18:07:58 2001 From: jasper at ivision.co.uk (Jasper Wallace) Date: Thu, 19 Apr 2001 17:07:58 +0100 (BST) Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419114829.A62655@sirius-cybernetics-corporation.com> Message-ID: On Thu, 19 Apr 2001, Guy Vegoda wrote: > Hi there all you internet people! Hello. > Questions: > > 1. Which platforms are we looking to support? > > I think that UNIX platforms would be easier for > development, and would cover the needs of the > majority of users. Also, ala Perl. > > A gui provides windows users with an opportunity > to use the sotware too. > > The same could be achieved on a win32 platform > under visual basic, but this would strain the GNU > lisence considerable, as well as denying use by > the UNIX users amongst us. FWIW Perl with the TK toolkit/widget set runs under both *nix and Windows. I still would prefer a web based solution. WRT people's comments about php vs. perl - php is very easy to learn, and it's very easy with perl to write code in such a way as to render it incomprehensible to anyone else (or to anyone who dosn't understand you particular dialect of perl). also doing compilcated datastructures in perl is a pain. you can't (afaik) do non web based gui's in php tho. -- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision at ivision.co.uk London SW7 2BE http://www.ivision.co.uk/ From michael.hallgren at teleglobe.com Thu Apr 19 18:16:16 2001 From: michael.hallgren at teleglobe.com (Hallgren, Michael) Date: Thu, 19 Apr 2001 17:16:16 +0100 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] Message-ID: > > Hi there all you internet people! > > Hello. 'lo, > > > Questions: > > > > 1. Which platforms are we looking to support? > > > > I think that UNIX platforms would be easier for > > development, and would cover the needs of the > > majority of users. Also, ala Perl. > > > > A gui provides windows users with an opportunity > > to use the sotware too. > > > > The same could be achieved on a win32 platform > > under visual basic, but this would strain the GNU > > lisence considerable, as well as denying use by > > the UNIX users amongst us. > > FWIW Perl with the TK toolkit/widget set runs under both *nix and > Windows. > > I still would prefer a web based solution. > Would as well. > WRT people's comments about php vs. perl - php is very easy > to learn, and > it's very easy with perl to write code in such a way as to render it > incomprehensible to anyone else (or to anyone who dosn't > understand you > particular dialect of perl). > > also doing compilcated datastructures in perl is a pain. hrm,... recent versions (5, 6) have gotten a _lot_ more freiendly than old 4. mh > > you can't (afaik) do non web based gui's in php tho. > > -- > Internet Vision Internet Consultancy Tel: > 020 7589 4500 > 60 Albert Court & Web development Fax: > 020 7589 4522 > Prince Consort Road > vision at ivision.co.uk > London SW7 2BE http://www.ivision.co.uk/ From djp at djp.net Thu Apr 19 15:44:13 2001 From: djp at djp.net (Dave Pratt) Date: Thu, 19 Apr 2001 15:44:13 +0200 (MET DST) Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: <20010419132354.A94132@enigma.ie> Message-ID: Hiya, This should be moved away from lir-wg as I suspect this topic is getting spammy and off-topic for most readers (it's nothing to do with setting LIR/RIR policy). Guy, can you set up a small mailing list to deal with IPMT and request subscribers ? With regards the mail thread, I've written quite a few HTML/WWW front ends using CGI.pm/PERL, and they are even modular - subject to the limitations of the perl module/package structure. See http://dcf.djp.net/141/ and http://dcf.djp.net/141/source/ The important thing is that the front end must be simple. We require forms and tables, a little javascript (submit on change and the like) nothing fancy. That is very simple using the CGI.pm perl module and the advantage of using perl throughout is a pretty big one. Cheers Dave On Thu, 19 Apr 2001, Niall Richard Murphy wrote: ->On Thu, Apr 19, 2001 at 01:06:20PM +0100, Guy Vegoda wrote: -> ->Hey Guy, -> ->> Will the back end DBMS not limit the speed quite a lot, ->> too? -> ->Surely not, especially if a database with a native IP type ->(for example, Postgres) is used, or an equivalent kludge. -> ->> I think you will find the majority of the users being ->> familiar with Perl already. -> ->Yes, as you suggest, some perl is necessary. The question is how much. -> ->> Easier? No. Faster, prettier, better? Yes, you're ->> right on that score. -> ->I have worked on a similar program in the past, and the hardest bit of ->it was getting the front-end code in a manageable and easily extendable/ ->modifyable state. Even with CPAN libraries the code is quite complex. ->PHP has the potential to make that a lot easier. -> ->> I think it would be interesting to take a straw pole ->> on this issue, anyhow. -> ->Well, I think I can be pretty sure that Perl will win, but that doesn't ->mean we couldn't save ourselves a lot of effort by being clever. -> ->Niall -> ->-- ->Enigma Consulting Limited: Security, UNIX and telecommunications consultants. ->Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. ->http://www.enigma.ie/ -> From gfontaine at vianetworks.nl Thu Apr 19 18:34:25 2001 From: gfontaine at vianetworks.nl (Guillaume Fontaine) Date: Thu, 19 Apr 2001 18:34:25 +0200 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: ; from jasper@ivision.co.uk on Thu, Apr 19, 2001 at 05:07:58PM +0100 References: <20010419114829.A62655@sirius-cybernetics-corporation.com> Message-ID: <20010419183425.E10984@guizy2.bart.nl> -On [20010419 18:09], Jasper Wallace (jasper at ivision.co.uk) wrote: >On Thu, 19 Apr 2001, Guy Vegoda wrote: > >> Hi there all you internet people! > >Hello. > >> Questions: >> >> 1. Which platforms are we looking to support? >> >> I think that UNIX platforms would be easier for >> development, and would cover the needs of the >> majority of users. Also, ala Perl. >> >> A gui provides windows users with an opportunity >> to use the sotware too. >> >> The same could be achieved on a win32 platform >> under visual basic, but this would strain the GNU >> lisence considerable, as well as denying use by >> the UNIX users amongst us. > >FWIW Perl with the TK toolkit/widget set runs under both *nix and >Windows. > >I still would prefer a web based solution. > >WRT people's comments about php vs. perl - php is very easy to learn, and >it's very easy with perl to write code in such a way as to render it >incomprehensible to anyone else (or to anyone who dosn't understand you >particular dialect of perl). > >also doing compilcated datastructures in perl is a pain. > >you can't (afaik) do non web based gui's in php tho. Actually you can make cross platform non web based gui's in php using php-gtk (you obviously have to use the php binary and not the apache module!) I like php for frontend's (never tried php-gtk tho :), but perl has all these modules on cpan.... > >-- >Internet Vision Internet Consultancy Tel: 020 7589 4500 >60 Albert Court & Web development Fax: 020 7589 4522 >Prince Consort Road vision at ivision.co.uk >London SW7 2BE http://www.ivision.co.uk/ Grts, -- Guillaume Fontaine VIA NET.WORKS Nederland From mlelstv at xlink.net Thu Apr 19 20:14:43 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Thu, 19 Apr 2001 20:14:43 +0200 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010403110059.A56522@sirius-cybernetics-corporation.com>; from Guy Vegoda on Tue, Apr 03, 2001 at 11:00:59AM +0100 References: <3946.985274717@ripe.net> <20010402170119.A70339@sirius-cybernetics-corporation.com> <20010402235044.B5559@xlink.net> <20010403110059.A56522@sirius-cybernetics-corporation.com> Message-ID: <20010419201443.A8635@xlink.net> On Tue, Apr 03, 2001 at 11:00:59AM +0100, Guy Vegoda wrote: > > -> searching of unassigned space using a combined exact-fit/first-fit > > strategy. > > Please expand on this. The tool will accept a number for the count of IP addresses to be assigned and search for a suitably aligned assignment. Obviously you will end with holes in your allocation whenever an assignment is returned. There are various alogrithms (coming by memory or disk space allocators) that try to get 'optimal' results by filling the holes. This tool does a two phase search, first it looks for assignments that fill holes completely and then it falls back and searches the first hole in the allocation that is large enough. > I don't want an end product that decides for you > which subnet you will be assigning. Why not ? Most assignments are completely arbitrary. There are two reasons to chose a specific subnet: aggregation and reservation. In both cases you do a bigger assignment first (which only exists privately, not in the RIPE database) and select your assignments from this block. -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Koen Bertoen ] From marck at rinet.ru Fri Apr 20 17:35:41 2001 From: marck at rinet.ru (Dmitry Morozovsky) Date: Fri, 20 Apr 2001 19:35:41 +0400 (MSD) Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010419201443.A8635@xlink.net> Message-ID: On Thu, 19 Apr 2001, Michael van Elst wrote: MvE> The tool will accept a number for the count of IP addresses to be assigned MvE> and search for a suitably aligned assignment. Obviously you will end with MvE> holes in your allocation whenever an assignment is returned. MvE> MvE> There are various alogrithms (coming by memory or disk space allocators) MvE> that try to get 'optimal' results by filling the holes. This tool does a MvE> two phase search, first it looks for assignments that fill holes completely MvE> and then it falls back and searches the first hole in the allocation that MvE> is large enough. MvE> MvE> MvE> > I don't want an end product that decides for you MvE> > which subnet you will be assigning. MvE> MvE> Why not ? Most assignments are completely arbitrary. There are two MvE> reasons to chose a specific subnet: aggregation and reservation. MvE> In both cases you do a bigger assignment first (which only exists MvE> privately, not in the RIPE database) and select your assignments MvE> from this block. I agreed, and we tried to first fill requests for, e.g., /24 in even blocks in /20 "reserved" for /24s, to be expanded to /23 when needed. Same algorithms for other popular block sizes, such as /27 and /26... Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From andrei at ripe.net Fri Apr 20 21:48:26 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 20 Apr 2001 21:48:26 +0200 Subject: Migration of the TEST database is completed Message-ID: <3AE0928A.F1840653@ripe.net> Dear Colleagues, The TEST database has been successfully migrated to v3 software. All objects in the TEST database were converted to RPSL compliant format. You can continue using the TEST database till 14 May as follows: - mail robot accepts updates in RIPE-181 format with some limitations. - mail robot accepts updates in RPSL format. After that day changes in robots' functionality will follow the plan fro the production database. Please see http://www/ripencc/pub-services/db/rpsl/announcement.html and http://www/ripencc/pub-services/db/rpsl/index.html for more information. Finding objects in the TEST Database: Do whois -h test-whois.ripe.net e.g. whois -h test-whois.ripe.net PB3-TEST The whois options that work in the RIPE Database also work in the TEST Database. We invite you to try them. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From joshua at roughtrade.net Sat Apr 21 18:59:55 2001 From: joshua at roughtrade.net (Joshua Goodall) Date: Sat, 21 Apr 2001 18:59:55 +0200 (CEST) Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010419201443.A8635@xlink.net> Message-ID: <20010421182941.S25644-100000@juice.shallow.net> On Thu, 19 Apr 2001, Michael van Elst wrote: > Why not ? Most assignments are completely arbitrary. There are two > reasons to chose a specific subnet: aggregation and reservation. > In both cases you do a bigger assignment first (which only exists > privately, not in the RIPE database) and select your assignments > from this block. Implementation suggestions that spring to mind: 1. since both perl and PHP support object techniques, make the subnet selection strategy a class (or module, or whatever the language-specific term of the week is). Instantiate a configured class to switch easily between strategies. This probably generalises for other program areas. 2. this system may have multiple users accessing it simultaneously. subnet selections etc cannot be allowed to conflict. PostgreSQL has far more mature support for the proper transactions that are motivated, and also has a native IP address/subnet datatype with corresponding operations. 3. multiple front-end support should be possible. I can guarantee that some LIRs will want to customise it, possibly drastically. Again, an object class (module) can support this, or you can just spit out XML and have XSLT parse it for HTML/pdf/etc - or use both strategies. This is surprisingly easy. 4. this is off-topic for the lir-wg and needs a dedicated mailing list! see [7] 5. once a dedicated list is up, a code license has to be chosen, and then a cvs/build server provided. I suggest these issues wait, but they are of equal importance with the choice of implementation language and deployment environment. 6. php can be used outside of a web interface, but perl is still more developer-friendly in the long run, has a wider range of libraries, greater code maturity, a larger userbase especially in this community, and proper structuring will allow development of Perl/TK interfaces to logic core without interference with web FE's - et cetera. Complicated data structures in Perl are *not* a pain - in fact, they're considerably more powerful, expressive and concise than those available in the language cores of all other language candidates, as anyone who's used the Schwartzian Transform will agree. 7. this is off-topic for the lir-wg and needs a dedicated mailing list! see [4] - Joshua From db-news at ripe.net Mon Apr 23 03:43:44 2001 From: db-news at ripe.net (DB-News) Date: Mon, 23 Apr 2001 03:43:44 +0200 Subject: First phase of the migration to the new RIPE Database is completed Message-ID: <200104230143.DAA04636@x43.ripe.net> Dear Colleagues, The new version of the RIPE Database is now up and running! All objects have been automatically converted to RPSL and loaded into the new version of the Database. The first phase of the migration has been successfully completed. The following mail robots accept updates to the RIPE Database: - updates are accepted in RIPE-181 format and automatically translated into RPSL. However, several restrictions apply to such updates: empty and misspelled attributes are not allowed, PGP auth is not supported. Also, RPSL authorization rules apply. - updates are accepted in RPSL format. This setup will be in place till 14 May, 2001. For more information about the migration please visit http://www.ripe.net/ripencc/pub-services/db/rpsl/announcement.html and http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html Best Regards, Andrei Robachevsky DB Group RIPE NCC From Robert.Kiessling at de.easynet.net Fri Apr 20 13:27:08 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Fri, 20 Apr 2001 13:27:08 +0200 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010419201443.A8635@xlink.net> References: <3946.985274717@ripe.net> <20010402170119.A70339@sirius-cybernetics-corporation.com> <20010402235044.B5559@xlink.net> <20010403110059.A56522@sirius-cybernetics-corporation.com> <20010419201443.A8635@xlink.net> Message-ID: <15072.7436.507848.193169@doncamillo.local.easynet.de> Michael van Elst writes: > There are various alogrithms (coming by memory or disk space allocators) > that try to get 'optimal' results by filling the holes. This tool does a > two phase search, first it looks for assignments that fill holes completely > and then it falls back and searches the first hole in the allocation that > is large enough. This is suboptimal. Assuming 10.0.0.0/28, 10.0.2.0/23 and 10.0.4.0/25 are free and you search for a /26. The above algorithm will find 10.0.2.0/23 and break it up, whereas it is better to break up 10.0.4.0/25 in order to avoid excessive fragementation. IMHO the algorithm should search for the first block of minimal size which is large enough to hold the assignment. Robert From maldwyn at ripe.net Fri Apr 20 13:43:02 2001 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 20 Apr 2001 13:43:02 +0200 Subject: [guy@sirius-cybernetics-corporation.com: IPMT specen.] In-Reply-To: Your message of Thu, 19 Apr 2001 18:34:25 +0200. <20010419183425.E10984@guizy2.bart.nl> References: <20010419183425.E10984@guizy2.bart.nl> Message-ID: <1394.987766982@ripe.net> Hi, Dave wrote: > This should be moved away from lir-wg as I suspect this topic is > getting spammy and off-topic for most readers (it's nothing to do > with setting LIR/RIR policy). We are preparing Specifications for IPMT and will send them to lir-wg next week. We would like input on them from the potential users of such I tool, and I think lir-wg is largely composed of such users, so I think the discussion of the Specifications belongs on lir-wg. I think the potential implementors of IPMT can then go somewhere else to discuss choice of programming language, database, UI, etc. Cheers, Maldwyn Morris Software Manager RIPE NCC From netmaster at space.net Fri Apr 20 15:20:22 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Fri, 20 Apr 2001 15:20:22 +0200 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010419201443.A8635@xlink.net>; from mlelstv@xlink.net on Thu, Apr 19, 2001 at 08:14:43PM +0200 References: <3946.985274717@ripe.net> <20010402170119.A70339@sirius-cybernetics-corporation.com> <20010402235044.B5559@xlink.net> <20010403110059.A56522@sirius-cybernetics-corporation.com> <20010419201443.A8635@xlink.net> Message-ID: <20010420152022.K3676@Space.Net> Hi, On Thu, Apr 19, 2001 at 08:14:43PM +0200, Michael van Elst wrote: > > I don't want an end product that decides for you > > which subnet you will be assigning. > > Why not ? Most assignments are completely arbitrary. There are two > reasons to chose a specific subnet: aggregation and reservation. > In both cases you do a bigger assignment first (which only exists > privately, not in the RIPE database) and select your assignments > from this block. Seconded. Such a tool would be very useful "give me a free /28 in Munich". Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From beri at kpnqwest.net Mon Apr 23 11:16:01 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Mon, 23 Apr 2001 11:16:01 +0200 (CEST) Subject: New DB and line continuation? In-Reply-To: <200104230143.DAA04636@x43.ripe.net> Message-ID: On Mon, 23 Apr 2001, DB-News wrote: >> The new version of the RIPE Database is now up and running! >> All objects have been automatically converted to RPSL and loaded into >> the new version of the Database. Congratulations! However, I have a question: When an attribute needs multiple lines to be described, the standard RPSL format requires the attribute name to be mentioned once, while successive lines are separted by spaces or commas (like you defined in the transition document as well). It used to be like that in the previous version of rpsl.ripe.net. However, right now, it seems to me there is a strange RIPE-181/RPSL mix in place. See example: * RADB and old REIMP.RIPE (standard RPSL): [beri at nix00 ~]$ rwhois -h whois.ra.net as-kq as-set: AS-KQ descr: KPNQwest European routes Formerly AS-EUNET AND NOT AS-EUNETQWEST members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889, AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857, AS3220, ... * RIPE (new format, RPSL): as-set: AS-KQ descr: KPNQwest European routes descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 While some of you might think this is not important, this is VERY important to some of us who make scripts for automating our tasks with the RIPE DB. Can anyone explain the reason of this RPSL syntax violation? Thanks! Regards, 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 Apr 23 11:24:41 2001 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 23 Apr 2001 11:24:41 +0200 Subject: New DB and line continuation? In-Reply-To: Your message of Mon, 23 Apr 2001 11:16:01 +0200. References: Message-ID: <200104230924.LAA29288@office.ripe.net> Hi, Berislav Todorovic, Thank you for reporting this. We are investigating. If you have anymore questions, please contact . Regards, A. M. R. Magee ______________ RIPE NCC Berislav Todorovic writes: * On Mon, 23 Apr 2001, DB-News wrote: * * >> The new version of the RIPE Database is now up and running! * >> All objects have been automatically converted to RPSL and loaded into * >> the new version of the Database. * * Congratulations! However, I have a question: * * When an attribute needs multiple lines to be described, the standard * RPSL format requires the attribute name to be mentioned once, while * successive lines are separted by spaces or commas (like you defined * in the transition document as well). It used to be like that in the * previous version of rpsl.ripe.net. However, right now, it seems to * me there is a strange RIPE-181/RPSL mix in place. See example: * * * RADB and old REIMP.RIPE (standard RPSL): * * [beri at nix00 ~]$ rwhois -h whois.ra.net as-kq * as-set: AS-KQ * descr: KPNQwest European routes * Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, * AS1234, AS1889, AS1891, AS1902, AS2043, * AS2049, AS2110, AS2135, AS2857, AS3220, * ... * * * RIPE (new format, RPSL): * * as-set: AS-KQ * descr: KPNQwest European routes * descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 * members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 * members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 * members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 * * While some of you might think this is not important, this is VERY * important to some of us who make scripts for automating our tasks with * the RIPE DB. * * Can anyone explain the reason of this RPSL syntax violation? Thanks! * * Regards, * 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 Mon Apr 23 12:16:27 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 23 Apr 2001 12:16:27 +0200 Subject: New DB and line continuation? References: Message-ID: <3AE400FB.781C177A@ripe.net> Dear Berislav, Berislav Todorovic wrote: > > On Mon, 23 Apr 2001, DB-News wrote: > > >> The new version of the RIPE Database is now up and running! > >> All objects have been automatically converted to RPSL and loaded into > >> the new version of the Database. > > Congratulations! However, I have a question: > > When an attribute needs multiple lines to be described, the standard > RPSL format requires the attribute name to be mentioned once, while > successive lines are separted by spaces or commas (like you defined > in the transition document as well). It used to be like that in the > previous version of rpsl.ripe.net. However, right now, it seems to > me there is a strange RIPE-181/RPSL mix in place. See example: > Indeed, we tried to introduce as little changes to objects look as possible, while staying RPSL compliant. In fact, RPSL defines members attribute as: Attribute Value Type as-set mandatory, single-valued, class key members list of or optional, multi-valued which means that one can have multiple 'members:' attribute, each of them may have a list of members separated by commas. So, formally there is no RPSL syntax violation. You can update your object to make it look like in RADB, both examples are accepted and valid in the RIPE database. Regards, Andrei > * RADB and old REIMP.RIPE (standard RPSL): > > [beri at nix00 ~]$ rwhois -h whois.ra.net as-kq > as-set: AS-KQ > descr: KPNQwest European routes > Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, > AS1234, AS1889, AS1891, AS1902, AS2043, > AS2049, AS2110, AS2135, AS2857, AS3220, > ... > > * RIPE (new format, RPSL): > > as-set: AS-KQ > descr: KPNQwest European routes > descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 > members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 > members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 > members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 > > While some of you might think this is not important, this is VERY > important to some of us who make scripts for automating our tasks with > the RIPE DB. > > Can anyone explain the reason of this RPSL syntax violation? Thanks! > > Regards, > 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 -- > --- _ _ ____ _ .--. ____ ____ __/_ --- > ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- -- Andrei Robachevsky DB Group Manager RIPE NCC From beri at kpnqwest.net Mon Apr 23 12:31:51 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Mon, 23 Apr 2001 12:31:51 +0200 (CEST) Subject: New DB and line continuation? In-Reply-To: <3AE400FB.781C177A@ripe.net> Message-ID: On Mon, 23 Apr 2001, Andrei Robachevsky wrote: >> So, formally there is no RPSL syntax violation. You can update your >> object to make it look like in RADB, both examples are accepted and >> valid in the RIPE database. OK - but will they be converted into multiple-members line format again or stay in the RADB-like form? Just curious ... Regards, 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 mir at ripe.net Tue Apr 24 16:57:06 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 24 Apr 2001 16:57:06 +0200 Subject: IPv6 addresses for Exchange Points Message-ID: <200104241457.QAA06305@x30.ripe.net> [Appologies for multiple postings. I suggest to keep the discussion on as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points From maldwyn at ripe.net Wed Apr 25 12:18:11 2001 From: maldwyn at ripe.net (Maldwyn Morris) Date: Wed, 25 Apr 2001 12:18:11 +0200 Subject: Proposed Agenda for Tools WG at RIPE 39 In-Reply-To: Your message of Wed, 18 Apr 2001 19:17:35 +0200. <20935.987614255@ripe.net> References: <20935.987614255@ripe.net> Message-ID: <17357.988193891@ripe.net> Proposed Agenda for Tools WG at RIPE 39 --------------------------------------- 1. Administratrivia a. Scribe b. List of participants 2. Agenda bashing 3. Election of WG Chair Maldwyn Morris is leaving the RIPE NCC and will be stepping down as Chair of the WG, so we need to chose a new Chair. Manuel Valente, the new RIPE NCC Software Manager, will stand for the position. 4. IPMT - Manuel Valente a. Specifications We have already produced basic requirements for the IP Management Tool ( IPMT ) and would now like your assistance to flesh out the specifications - a real _working_ group ! Anyone who has used a similar tool or might use IPMT is encouraged to come along and help. b. Developers Group We would like to organise a group of people willing to help implement IPMT. 5. Tools and Techniques - Manuel Valente We would like to discuss proposed and existing tools or techniques of use to LIRs. If you have tools or ideas of your own, please bring them along. Cheers, Maldwyn Morris Software Manager RIPE NCC From ncc at ripe.net Wed Apr 25 15:17:21 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 25 Apr 2001 15:17:21 +0200 Subject: portable address space Message-ID: <200104251317.PAA25312@office.ripe.net> Dear all, At the upcoming RIPE meeting next week, the RIPE NCC will put forward a proposal attempting to clarify current policy on independent/portable address space. We are seeking the communities input on this matter. The RIPE NCC is currently experiencing an increased demand for portable address space, clearly visible through the amount of new members signing up from a need for portable address space but also through the amount of PI (Provider Independent) address requests received at the RIPE NCC. At this time there is no clear and consistent policy on any of these types of portable address space. - PI address space is discouraged and requestors are informed of disadvantages with PI space and what possible implications there may be. However, there are no criteria for obtaining PI address space. - PA allocations can be obtained by anyone who is a member of the RIPE NCC. (The RIPE NCC membership is open.) The LIR is only required to justify the first assignment out of that address block. As all members are required to request and justify each assignment made to customers or own infrastructure, we feel that current poorly defined PA Allocation criteria create an inconsistency in policy. In practice it means that anyone justifying the need of one IP address can receive a PA allocation (currently a /20 = 4096 addresses). This has resulted in an enormous growth of new members over the last three years. Whilst ARIN has a clearly defined policy on portable address space, APNIC has experienced the same dilemma as the RIPE NCC with their similar policies on portable address space. This was brought up and discussed at the APNIC meeting in Kuala Lumpur, March 2001. (see URL below.) As demonstrated in several recent studies of the changes in the Internet over the last years, it is clear that there is an increase of multi-homing taking place globally, an increase of smaller routes being announced in the Internet and an increased need for portable address space. The RIPE NCC wishes to develop a clear and consistent policy for portable address space in a realistic and pragmatic manner that also accommodates this increased need for portable address space. We will at the upcoming lir-wg meeting present statistics showing this trend and suggest possible steps forward. We wish to request the communities input in this discussion and we look forward to a fruitful discussion. Kind regards Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net REFERENCES: -------------------- Policy documentation: "European Internet Registry Policies and Procedures", section 3.4.2.PA vs PI Space http://www.ripe.net/ripe/docs/ripe-185.html#toc34 "Provider Independent versus Provider Aggregatable Address Space" http://www.ripe.net/ripe/docs/ripe-127.html APNIC policy documentation: http://www.apnic.net/docs/add-manage-policy.html ARIN policy documentation: http://www.arin.net/regserv.html Presentations and papers: "Architectural Requirements for Inter-Domain Routing in the Internet" - Geoff Huston http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt "The State of BGP routing" http://www.telstra.net/gih/papers/ietf/ietf50-plenary.pdf "Consistent and realistic policy framework for 'Portable' allocation and assignment" - Paul Wilson http://www.apnic.net/meetings/presentations/pa-pi-criteria.ppt Global policy document: "RIR comparative Policy Overview" http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.html From ncc at ripe.net Wed Apr 25 16:11:43 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 25 Apr 2001 16:11:43 +0200 Subject: Hostmaster Centre at RIPE 39 Message-ID: <200104251411.QAA03162@office.ripe.net> Dear all, Ripe NCC Registrations Services are pleased to announce that during the RIPE 39 Meeting in Bologna, we will open a Ripe NCC Hostmaster Centre. Ripe NCC Hostmasters will be available for any IP and ASN request questions, and also any general policy questions. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 30. 12:30 - 14:00 Tuesday May 1. 9:00 - 17:30 Wednesday May 2. 12:30 - 14:00 & 16:00 - 17:00 Thursday May 3. 9:00 - 14:00. Friday May 4. CLOSED. (IP request Tutorial, 14.00-17.30) We look forward to meeting you. Regards, Ripe NCC Hostmasters From ncc at ripe.net Wed Apr 25 16:11:43 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 25 Apr 2001 16:11:43 +0200 Subject: Hostmaster Centre at RIPE 39 Message-ID: <200104251411.QAA03162@office.ripe.net> Dear all, Ripe NCC Registrations Services are pleased to announce that during the RIPE 39 Meeting in Bologna, we will open a Ripe NCC Hostmaster Centre. Ripe NCC Hostmasters will be available for any IP and ASN request questions, and also any general policy questions. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 30. 12:30 - 14:00 Tuesday May 1. 9:00 - 17:30 Wednesday May 2. 12:30 - 14:00 & 16:00 - 17:00 Thursday May 3. 9:00 - 14:00. Friday May 4. CLOSED. (IP request Tutorial, 14.00-17.30) We look forward to meeting you. Regards, Ripe NCC Hostmasters From andrei at ripe.net Thu Apr 26 16:07:47 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 26 Apr 2001 16:07:47 +0200 Subject: The status of the migration iissues Message-ID: <3AE82BB3.8BFCFF7F@ripe.net> Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by . Until 14th of May, processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, , and will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From noc at entire-systems.com Thu Apr 26 16:39:08 2001 From: noc at entire-systems.com (Daniel Roesen) Date: Thu, 26 Apr 2001 16:39:08 +0200 Subject: The status of the migration iissues In-Reply-To: <3AE82BB3.8BFCFF7F@ripe.net>; from andrei@ripe.net on Thu, Apr 26, 2001 at 04:07:47PM +0200 References: <3AE82BB3.8BFCFF7F@ripe.net> Message-ID: <20010426163908.A27660@entire-systems.com> Dear Andrei, On Thu, Apr 26, 2001 at 04:07:47PM +0200, Andrei Robachevsky wrote: > 1. PGP signed messages sent to didn't pass > authorization checks > > This was fixed on 24th of April. Please note that PGP signed updates > cannot be processed by . There should be a note that quoted-printable encoded signed updates are still not processed because of a deficiency of the MIME parser, as confirmed by A.M.R. Magee who asked for public discussion on this topic. Best regards, Daniel -- Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9 From ripe-dbm at ripe.net Thu Apr 26 16:07:47 2001 From: ripe-dbm at ripe.net (ripe-dbm at ripe.net) Date: Thu, 26 Apr 2001 16:07:47 +0200 Subject: The status of the migration iissues In-Reply-To: <3AE82BB3.8BFCFF7F@ripe.net> References: <3AE82BB3.8BFCFF7F@ripe.net> Message-ID: Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by . Until 14th of May, processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, , and will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From hph at online.no Thu Apr 26 19:02:28 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 26 Apr 2001 19:02:28 +0200 Subject: Call for agenda items & draft agenda References: <004201c0b7e0$7deb8c00$0500000a@hph> Message-ID: <003b01c0ce72$ad40c2b0$0600000a@hph> Dear WG, Please find enclosed Version 2 of the draft agenda for the lir-wg Please get in touch with me if I have missed any agenda items. Draft Agenda v2.0 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. RIPE NCC Quality of Service - 17th of May Task force - goal reached or what to do next ? 6. Portable address space 7. Pre RIR address space migration from ARIN to RIPE/APNIC 8.Election of WG Chair and co-chair 9. Report from The ASO: AC happenings and GA 10.Closure of the ICANN ad Hoc Group on numbering 11. Global vs Regional Policy 12. RIR Comparative overview 13. ASO Call for nominations 1. october - 90 days must be out before july 1st 14. IPv6 policy - Summary of joint session 15. IPv6 for IXPs 15 Open Mike. Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions From hph at online.no Mon Apr 30 18:01:41 2001 From: hph at online.no (Hans Petter Holen) Date: Mon, 30 Apr 2001 18:01:41 +0200 Subject: Call for agenda items & draft agenda References: <004201c0b7e0$7deb8c00$0500000a@hph> <003b01c0ce72$ad40c2b0$0600000a@hph> Message-ID: <000d01c0d18e$dd37d980$2906e1c3@hph> 2 new items: 16 HPHs proposal for modifications on how we develope policy 17 Kurt Kaysers proposal on individual membership (for discussion on wether this should be brought to the AGM or not) -hph | Dear WG, | Please find enclosed Version 2 of the draft agenda for the lir-wg | | Please get in touch with me if I have missed any agenda items. | | Draft Agenda v2.0 | | 1.Admin - scribe, participant list, charter, mailing-lists | 2.Agenda | 3.RIPE 38 minutes & actions | 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno | 5. RIPE NCC Quality of Service - 17th of May Task force - goal reached or | what to do next ? | 6. Portable address space | 7. Pre RIR address space migration from ARIN to RIPE/APNIC | | 8.Election of WG Chair and co-chair | 9. Report from The ASO: AC happenings and GA | 10.Closure of the ICANN ad Hoc Group on numbering | | 11. Global vs Regional Policy | 12. RIR Comparative overview | 13. ASO Call for nominations 1. october - 90 days must be out before july | 1st | | 14. IPv6 policy - Summary of joint session | 15. IPv6 for IXPs | | 15 Open Mike. | | Actions from last meeting: | | 35.4 NCC PGP Key exchange procedure | 35.5 NCC Implement PGP for hm | 36.5 Chair Assignment window applied on infrastructure | 36.6 AP Collect arbitrators | 36.7 NCC Keep lir-wg updated on pre RIR address space changes | 37.1 WG Further discuss restoring the transparency | 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy | 37.3 M17 Work with the RIPE NCC to implement suggestions | | From david at IPRG.nokia.com Sun Apr 29 22:41:43 2001 From: david at IPRG.nokia.com (David Kessens) Date: Sun, 29 Apr 2001 13:41:43 -0700 Subject: agenda for IPv6 working group RIPE39 Message-ID: <20010429134143.B12625@iprg.nokia.com> Hi, Below follows the final version of the agenda for the ipv6 wg. The second part of our session will be used for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. 3G and IPv6 (Niall Murphy) E. IPv6 deployments at Jippii (Jan-Ahrent Czmok) F. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg G. Draft on allocation sizes http://www.enigma.ie/articles/global-ipv6-alteration.html (Niall Murphy) other info: http://www.djp.net/ipv6/proposal.html http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.html (Dave Pratt) H. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---