- db-wg - mailman.ripe.net

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

Fwd: [Apnic-announce] Privacy of customer assignment records - implementation update
by leo vegoda 23 Sep '04

23 Sep '04

Hi, APNIC have announced a change in the default behaviour of their Whois server. The change will be made on 30 September. People using their Whois service from this region may be interested in the announcement. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC Begin forwarded message: > From: APNIC Secretariat <secretariat(a)apnic.net> > Date: September 23, 2004 2:02:27 am BST > To: apnic-announce(a)apnic.net > Cc: Subject: [Apnic-announce] Privacy of customer assignment records - > implementation update > Reply-To: apnic-talk(a)apnic.net, secretariat(a)apnic.net > > Dear colleagues, > > This is an important announcement on the implementation of APNIC > approved proposal prop-007-v001 regarding privacy of customer > assignment records. The proposal document, presentation, minutes, and > discussion are available at: > > http://www.apnic.net/docs/policy/proposals/prop-007-v001.html > > The APNIC Secretariat will be implementing this proposal on 30 > September 2004. > > Please note that after this date, customer assignment objects will no > longer be visible in the APNIC Whois Database, unless the APNIC > account holder chooses to make public the customer records for their > allocated address range. > > A set of Frequently Asked Questions about this project is now > available at: > > http://www.apnic.net/info/faq/privacy-faq.html > > If you have any concerns or questions regarding this policy, please > contact the APNIC helpdesk at: > > E-mail: helpdesk(a)apnic.net > Phone: +617 3858 3188 > Fax: +617 3858 3199 > > Regards > > ______________________________________________________________________ > APNIC Secretariat <secretariat(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ______________________________________________________________________ > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce >

2 1

Abuse contacts in RIPE database and whois
by Rodney Tillotson 22 Sep '04

22 Sep '04

In this afternoon's session of the Anti-spam WG we discussed the issue of publishing abuse contacts and I agreed to present this consensus view and request. As time is short this is not yet published in the minutes of the meeting, but it will be! Rodney Tillotson Chair, RIPE anti-spam WG =========================================================== The Anti-spam WG asks the Database WG to take some timely action to improve the availability of abuse contacts for IP addresses allocated through RIPE: 1. to publish an explicit abuse contact address where possible for every address; 2. to lower the profile of other addresses currently in the database and published through whois, which were never intended for the abuse function. While it is for the Database WG to decide the best way to implement such improvements, the Anti-spam WG noted that of the various technical changes which have been proposed or partly implemented, one combination which we would find acceptable is: A. modify the IRT object to include an explicit 'abuse-mail' attribute and to remove the mandatory requirement for PGP or similar authentication (or introduce a similar new object with those properties); and B. modify the default behaviour of the whois interfaces to find and present an abuse address if there is one and to suppress other e-mail addresses. 22nd September 2004. ===========================================================

1 0

Agenda V3
by Titley, Nigel 16 Sep '04

16 Sep '04

Gentlefolk, Following a kind offer by Shane Kerr to give a run down on CRISP please find version 3 of the DB WG agenda. 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: [db-wg] draft agenda (V1) for DB-WG meeting, RIPE 49, Manches ter, UK
by Titley, Nigel 15 Sep '04

15 Sep '04

MarcoH wrote: > Hate to come up with it again, but there are various actions points > open > on the abuse-c stuff. One of them lists the 'implement whatever > concensus there is on the mailinglist'. > > These should already be on the agenda as open action points, but it > might > be worth planning some time for discussion or at least an overview of > what > the outcome of the mail discussion was. Sounds like a good idea. Do we have any volunteers to do a short presentation on where we got to? > It's hard to say there is consensus on this subject, although in they > end there weren't much comments posted and everybody seems to be > happy (or > tired of it). I think it just fizzled out. I'm not sure that we got to any consensus. 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

draft agenda (V1) for DB-WG meeting, RIPE 49, Manchester, UK
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

Dear DB-WG community, attached please find the draft agenda V1 for the DB-WG meeting during RIPE49 in Manchester, UK. As some of us have still been on vacation recently, we may have to update the draft agenda as we get closer to the meeting date. Please feel free to propose additional topics by either replying to the WG mailing list or in private mail to Nigel (who has volunteered to manage the meeting in Manchester - thank you very much!) and myself. Have a nice and successful meeting in Manchester! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 7-SEP-2004 12:55:00 UTC

7 12

Re: [db-wg] domain: object normalization
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

I'd like to come back to the *original* question or suggestion: to teach the DB software to accept FQDN notation (trailing ".") for lookup keys that denote domain names. Pro / Con? As a dumb user of the DB I definitely stumble into that one myself, sometimes, so I am in favour of this (hopefully simple?) change. Btw, if this gets implemented, it should also work for the referral domain objects! Wilfried.

2 1