October 2004 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Deprecation of the NONE Authentication Scheme
by Ziya Suzen 08 Nov '05

08 Nov '05

Dear Colleagues, As announced at RIPE 47 the NONE authentication scheme will be deprecated. After 26 April 2004 the RIPE Whois Database will not accept updates using the NONE authentication scheme. If you have objects protected by a MNTNER object which has the NONE authentication scheme, please assign another authentication scheme or create another MNTNER object to protect these objects. If you are a RIPE NCC member you can create new MNTNER objects through the LIR Portal or send your update to <auto-dbm(a)ripe.net>. History and details: -------------------- 1. Motivation The RIPE Database protects data from unauthorised modification through the use of references to maintainer objects. The maintainer objects contain an "auth:" attribute which specifiy how a user is authenticated during updates to the database. One of the allowed authentication schemes is "NONE", which is actually not an authentication at all, but rather specifies that no authentication is necessary. NONE is intended to be used consciously, as a notification facility or as a means to tag objects. In April 2003, a proposal was sent to the Database Working Group by Hank Nussbacher: It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. It is likely that in many cases NONE is used simply because it is easy. Currently approximately 500 maintainers use NONE - about 5% of all maintainers. 2. Plan Normally with a database cleanup effort, an announcement is sent to the appropriate mailing lists, posted to the RIPE web page, and also sent to the specific users affected. A period of time for cleanup is given. Finally, if the users have not fixed the data then it is modified. However, for the NONE deprecation, it is inadvisable to do this as it means announcing what is in effect a security vulnerability. Also, our operational experience with past cleanups shows that most users do not really participate through the phases of the effort. Therefore, the plan for MNTNER objects with the NONE authentication scheme is: o Announcement only to db-wg mailing list. (This announcement) o Remove "auth: NONE" attributes from all MNTNER objects, by changing them to a "remarks:" attribute with a URL explaining the change. o If that is the only authentication scheme, update the mntner objects, adding MD5-PW with a generated password. o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the objects, explaining the change and including the new password if one is added. o Passwords can be requested via an e-mail to <ripe-dbm(a)ripe.net>. The reply with the password will be sent to the same contacts. After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact <ripe-dbm(a)ripe.net> for assistance. 3. RIPE-NCC-NONE-MNT A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to objects without any maintainer when the database was converted from RIPE-181 format to RPSL format in April 2001. There is a remark in these objects which includes the following: remarks: The RIPE NCC will never use this maintainer object to remarks: enforce any sort of control over user's objects. It is possible this could have been interpreted to mean that no restriction would ever be added to the object. One use of the RIPE-NCC-NONE-MNT has been to allow the creation of objects representing routing policy for resources not allocated or assigned by the RIPE NCC. This is done by using "mnt-routes: RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate. A new maintainer object will be created for these cases, with a well- known password, published in the object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE upd-to: ripe-dbm-notify(a)ripe.net auth: MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1 remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040301 source: RIPE The main use of this maintainer is for INETNUM objects. There are approximately 60000 such objects - about 6% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. For objects using RIPE-NCC-NONE-MNT: o If there are other "mnt-by:" attributes it will be changed to a "remarks:" attribute. o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT, which has a locked password (or PGP key). o A "remarks:" attribute will be added explaining how to generate a maintainer. o An e-mail will be sent to the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "notify:" attributes of the objects, explaining the change and giving a URL which will help to generate a new maintainer or assign another existing maintainer. o At the URL, the object will be automatically updated to have a new maintainer. o After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact ripe-dbm(a)ripe.net for assistance. 4. Other maintainers with "auth: NONE" The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be deleted in the 2001 person cleanup. It can be removed and the maintainer deleted. The LIM-MNT is used for limericks. It will have a well-known password similar to the RPSL maintainer. It will also be maintained by another maintainer (not itself, as currently). -- Ziya Suzen RIPE NCC

4 5

Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 19 Jan '05

19 Jan '05

Gentlefolk, Niall has pointed out some major inaccuracies in the draft minutes, which I have corrected. Apologies for this. However luckily none of the action points have been impacted. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

3 2

ccTLD data in RIPE DB?
by Ulf Kieber 26 Oct '04

26 Oct '04

Re, weren't ccTLD domain registries supposed to remove their stuff from the database? Do a "whois -r -T domain -i notify notify(a)nic.gm". Which ccTLDs are still holding their registry data in the RIPE DB anyway? -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

3 3

RPSLng database deployment?
by Bernhard Schmidt 20 Oct '04

20 Oct '04

Dear all, having missed the last RIPE meeting I'm unfortunately somewhat out of date regarding this, but could someone please enlighten me about the current plans for deployment of RPSLng in the regular RIPE database? I am using rpslng.ripe.net, but unfortunately almost noone else does. Running a network without any sustainable prefix authorization sucks quite hard, it is a real pain to have to contact your upstream by mail if you have a new prefix (besides other things). Are there any problems with RPSLng currently? Thanks Bernhard

9 12

Recent Database update changes
by Denis Walker 13 Oct '04

13 Oct '04

[ Apologies for duplicate messages ] Dear Colleagues, In preparation of a new release of the Whois software we have fixed several bugs and implemented some of the simple features asked for over the last few months for the update program, dbupdate. A brief description follows of the features implemented. 1) Change to the overall result of a mail update message. During the re-structuring of the dbupdate program we changed the way we report the overall result of a mail update. This caused some confusion and we have now returned to the behaviour of the previous version of dbupdate. To make this clear here are the outcomes we now report: A blank update message - FAILED: ANY object update failed - FAILED: Otherwise - SUCCESS: 2) Handling of keywords in the Subject: line of a mail update. Currently there are only two keywords used by dbupdate. These are NEW and HELP (HOWTO is also valid but taken to mean the same as HELP). NEW forces all objects found in the mail message to be treated as a creation request. Any object that already exists will result in an error. HELP returns help text. To use a keyword it has to be put in the Subject: line of the mail message, with NO other words present. If any other word is found for example Subject: NEW objects then none of the words are actioned as keywords and they are all reported in the acknowledgement reply as invalid keywords. In this context it is impossible for dbupdate to know if a word is a keyword. As many users often include their own reference in the Subject: line it means it is impossible for them to also use a keyword and they always get their references reported in the Warning messages af the acknowledgement. To overcome these problems we have introduced a KEYWORDS: tag. When this tag is found in a Subject: line all text up to and including this KEYWORDS: tag is ignored by dbupdate. Only what follows this tag is checked for valid keywords. The same rules apply as before. If a word is found after the KEYWORDS: tag that is not a valid keyword none of the words are actioned as keywords. In this case all the words following the KEYWORDS: tag are reported as invalid keywords in the acknowledgement reply. Adding the KEYWORDS: tag at the end of a Subject: line means that valid keywords can still be used with a users reference in the same line. By adding the KEYWORDS: tag at the end of the Subject: line with no keywords following it means that the users reference will not be reported as invalid keywords. The default behaviour is unaltered. A keyword can still be placed on a line with no other words and actioned. We could easily make another change, if users would prefer it, so that keywords will ONLY be accepted if they follow the KEYWORDS: tag. This would make the default behaviour ignore the whole Subject: line and not report any of it as errors if the KEYWORDS: tag is not found. This default behaviour may be more appropriate to the way the Subject: line is currently used in most cases. Please let us know if this is preferred. All keywords and the KEYWORDS: tag are case insensitive. 3) Differnce in notification messages We have been asked to highlight changes in the notification message between the old and new objects for a modification operation. This is particularly useful when "import:" and "export:" attributes are changed in large AUT-NUM objects. This has now been implemented as a selectable option. To request it the user includes the keyword DIFF. When this DIFF keyword is used each object in the notification message that is a modify operation will include a difference before the standard output of the old and new versions of the objects. So the output will have the difference listing followed by the old and new objects. For example, a new subject line may look like this Subject: changes to aut-num: as1234 KEYWORDS: DIFF The difference is the standard unix diff, but with one slight change. In our acknowledgement and notification messages we have used three dashes --- followed by a new line to signify the start of a section relating to an object. This is to make it easy to parse the output and find the start of each object in the message. Unfortunately diff also uses --- to seperate lines that have changed. So we have had to replace --- with === in the diff output. If the DIFF keyword is not used the output remains unchanged. Using a simple PERSON object as the example the new output is as follows: --- OBJECT BELOW MODIFIED: Differences in [person] TP10-DB-TEST 7c7,8 < notify: case040-1(a)ripe.net === > changed: dbtest(a)ripe.net 20040101 > notify: case040-2(a)ripe.net person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest(a)ripe.net 20020101 notify: case040-1(a)ripe.net source: DB-TEST REPLACED BY: person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest(a)ripe.net 20020101 changed: dbtest(a)ripe.net 20040101 notify: case040-2(a)ripe.net source: DB-TEST 4) Include person/role name in creation results. The last additional feature is to include the name of a PERSON or ROLE object in the acknowledgement output after a successful creation. Previously only the new nic-hdl was listed. For example, if two PERSON objects are created using AUTO- nic-hdls for Denis Walker and David Wilkinson the reply would only say DW23-RIPE and DW24-RIPE have been created. The user would then have to do a whois lookup to determine which was which. The reply now states: --- Create SUCCEEDED: [person] DW23-DB-TEST Denis Walker --- Create SUCCEEDED: [person] DW24-DB-TEST David Wilkinson Regards Denis Walker RIPE NCC Software Engineering Department.

7 6

Draft Minutes DB-WG session RIPE 49
by Titley, Nigel 08 Oct '04

08 Oct '04

Gentlefolk, Please find the first draft of the minutes of the DB-WG session at RIPE 49 Comments to the list, or direct to me. As usual, I'll publish these on the website in about a week's time. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [ipv6-wg@ripe.net] RPSLng database deployment?
by Tony Hain 07 Oct '04

07 Oct '04

Sorry, this was a reply to the wrong message. Tony > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, October 06, 2004 5:09 PM > To: 'Bernhard Schmidt'; 'db-wg(a)ripe.net' > Cc: 'ipv6-wg(a)ripe.net' > Subject: RE: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > A few additional comments now that the text is cleaned up: > > The last sentence of 2.1 is out of context to the heading. The point it is > making really belongs in 2.2. It makes a nice lead-in sentence, and taking > the word 'these' out would probably fix the sentence to make sense as the > start of the next section. > > 2.2 ... ', and hence there is no specific security value in the NAT > function.' That should probably be a stand alone sentence with the 'NAT' > string replaced by 'address translation'. > > The perceived security comes from the lack of pre-established mapping > state. Dynamically establishing state in response to internal requests > prevents unexpected external connections to internal devices. > > ... the security policy is already likely to consist of multiple > components such as Firewalls, data-filters activity logging and intrusion > detection systems. Simplified forms of these for the less security aware > users could assist to make their private networks more secure. > -delete list- > > 2.4 ... they do prevent the external tracking and profiling of individual > host computers by means of their IP addresses. > -(2.3 just talked about how to track if one has access to the NAT, so this > one needs to be explicit about external)- > > ... which some enterprises believe is a useful ... > - replace 'enterprises' with 'network managers' - > > 2.5 ... unique and routable IPv4 address will continue increasing as > allocation policies tighten so that they become more difficult to obtain. > > 'This mechanism allows the simultaneous usage of certain IPv4 prefix for > various end-customers or end-systems. The overall benefit to the provider > is that fewer globally unique IPv4 addresses are required.' > - This is confusing unless the reader understands the need for stability > in IPv4 end system configurations. RE: how does simultaneous use of an > IPv4 address allow the ISP to use fewer addresses? It really doesn't. The > ISP will use as many addresses as it takes for independent instances of an > application. What NAT does in this situation is allow the IPv4 end systems > to have stable addresses that may overlap with other organizations, and > the ISP only needs as many public addresses as there are simultaneous > instances of a given app. - > > This type of local control of address resources allow a clean and > hierarchical addressing structure in the network that is not restricted by > the size of the publicly routed address pool. > > 2.6.1 ... larger (probably with less-administrative overhead) IPv4 address > range ... > > 2.6.2 'only have only' -->> 'have' > > 'For this type of private networks mainly RFC 1918 addressing is used > internally to reduce the needed amount of global routable prefixes, > because there no need for owned IPv4 prefixes by the enterprise and for > simplicity of the administrative overhead by the lack of a dedicated NOC.' > - I don't buy the argument to begin with. 'Lack of need' is bogus and we > shouldn't propagate it here because it will deflate the value of the IPv6 > argument later. We should put this in the context of a cost trade-off, > forfeiting some applications in favor of reduced access costs. How about: > Small networks typically deploy RFC 1918 addressing internally to limit > the explicit charges for publicly routable addresses. This approach also > has the advantage of avoiding the administrative overhead and dedicated > NOC associated with acquiring blocks of publicly routed address space. > > 2.6.3 ... 'due to the operational stateful operation' ... > - I think the first operational should go. > > 2.7 - drop the last sentence. For one those savings are only short term, > the long term costs of dealing with conflicting space will be higher. For > two, the point of the paper is to show how IPv6 makes things better, and > even the simplified renumbering will appear to be more expensive than > throwing a NAT at the problem. If you really want to say something about > cost, put it in the context of -perception-, -short term-, and -simple-. > - > > Why is 2.8 different from 2.2? > > I though you were going to align the numbering. > 2.1 -> 3.2 > 2.2 -> 3.3 > I think we should be able to summarize with a table like: > Function 2.x (IPv4) 3.x (IPv6) > x.1 Simple Gateway simple management DHCP-PD > x.2 Simple security stateful filter reflexive acl > x.3 tracking nat state table global uniqueness > x.4 topology hiding nat as virtual presence MIPv6 > x.5 addressing control RFC 1918 RFC 3177 & ULA > x.6 address allocation RFC 1918 RFC 3177 & ULA > x.7 renumbering RFC 1918 Multiple addr/interface > > Just trying to populate that table might clean up the overlaps and make it > clear what the point of each section should be. If we can delineate the > functions in crisp one or two word labels we can both make it simpler to > understand and more consistent between the versions. As it is even I am > having trouble figuring out if that table is correct. For example 3041 is > listed in 3.5, but it does absolutely nothing for topology hiding. Yes > privacy is one aspect of topology hiding, but end system privacy has > nothing to do with masking the network topology. > > 3.2 - why are renumbering & firewalls being discussed in the simple > gateway section? - > > 3.3 - the first two paragraphs are really summary material about ongoing > evolution in best practices and shouldn't be here. The last paragraph is > somewhat unrelated to the NAT->IPv6 effort. If it stays, comparable text > should be in the IPv4 section that makes it clear that open ports through > a nat will map to multiple machines, so configured state to run servers in > the private space are just as exposed as they would be without the nat. - > > 3.4 - all of this appears to be too much detail except the next to last > paragraph. The last paragraph is about IPv4 and is already stated there so > it should not be here. - > > 3.5 - End system privacy and network topology privacy are very separate > topics and shouldn't be in the same section. - > > - recommending that people use different subnet structures for internal & > external is just asking for trouble. Most 1st level ops have a hard enough > time with subnets anyway, so making this unnecessarily complex is just a > bad idea. 'Untraceable'/host-routes are a much better plan yet not even > mentioned here. - > > 3.6 - should be replaced with: > IPv6 provides for autonomy in local use addresses through ULAs (draft-???). > At the same time IPv6 simplifies simultaneous use of multiple addresses > per interface so that a NAT is not required (or even defined) between the > ULA and the public Internet. Nodes that need access to the public Internet > should have a global use address, and may simultaneously have a local use > ULA. Since the IPv6 address space for global use is not a scarce resource > like it is in IPv4, each network should be able to acquire a sufficient > quantity for its needs. While global IPv6 allocation policy is managed > through the Regional Internet Registries, it is expected that they will > continue with derivatives of RFC 3177 for the foreseeable future. > > 3.7.1 - seems to wander over several topics without a point. - > > 3.7.3 - if the ISP is allocating /128's then 3041 is not possible. > > 3.7.x - I still don't see the point in separating these out. There is > nothing that says an ISP can't or shouldn't use DHCP-PD for *every* > customer interface. The point is the length is flexible so any size > network fits. If there is to be a static mapping it should be done on the > back side of the DHCP server. The only time you might get into size > distinction here is if the customer is not part of the ISP aggregate and > is therefore injecting routes. The thing is injecting routes is not a > function of IPv4/NAT, so it really doesn't belong in this document. - > > 3.9 is really a subset of 3.3 > > I need to call it a day. I don't have a problem with the current draft > going out as a -00, but we should follow it with a fixed up -01 asap. > > Tony > > > > -----Original Message----- > > From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf > Of > > Bernhard Schmidt > > Sent: Wednesday, October 06, 2004 2:24 PM > > To: db-wg(a)ripe.net > > Cc: ipv6-wg(a)ripe.net > > Subject: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > > > Dear all, > > > > having missed the last RIPE meeting I'm unfortunately somewhat out of > > date regarding this, but could someone please enlighten me about the > > current plans for deployment of RPSLng in the regular RIPE database? > > > > I am using rpslng.ripe.net, but unfortunately almost noone else does. > > Running a network without any sustainable prefix authorization sucks > > quite hard, it is a real pain to have to contact your upstream by mail > > if you have a new prefix (besides other things). > > > > Are there any problems with RPSLng currently? > > > > Thanks > > Bernhard

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training 04 Oct '04

04 Oct '04

Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Rumy Kanis Training Services Manager RIPE NCC **************************************************************************** COURSE DATES AND VENUES ======================== Date: Tuesday 23 November 2004 Time: 0900 - 1700 Location: Damascus,Syria AND: Date: Friday 14 January 2005 Time: 0900 - 1700 Location: Berlin, Germany AND: Date: Friday 18 March 2005 Time: 0900 - 1700 Location: Barcelona, Spain AND: Date: Friday 15 April 2005 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Friday 22 April 2005 Time: 0900 - 1700 Location: St. Petersburg, Russian Federation ***************************************************************************** REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0