- db-wg - mailman.ripe.net

Maintenance on RIPE Whois Server, 10 November 2003
by DB-News 07 Nov '03

07 Nov '03

Dear Colleagues, [apologies for duplicate messages] Next Monday, 10 November 2003, we need to perform a maintenance work on the RIPE Whois Server to replace a faulty piece of hardware. During the maintenance work, - Whois Database updates will be stopped, - all update mails to <auto-dbm(a)ripe.net> will be queued to be processed later, - Webupdate and syncupdate interfaces will be unavailable, - The whois queries will _not_ be interrupted. The maintenance work will start at 12:00 UTC (13:00 Amsterdam time) on 10 November 2003 and expected to last 2 to 3 hours. We apologise for the convenience caused. Please do not hesitate to contact <ripe-dbm(a)ripe.net> for any questions. Best regards, -- Engin Gunduz RIPE NCC

1 0

RE: [db-wg] Should the "e-mail" attribute be mandatory for the "p erson" object?
by Titley, Nigel 03 Nov '03

03 Nov '03

Thor Kottelin wrote: > Folks, > > Email is the preferred communication medium when troubleshooting > internetworking problems. Time and time again, "inetnum" > objects with no > valid email address cause grief. In the absence of relevant "e-mail" > attributes, desperate administrators sometimes send mail to > addresses found > in "changed" and "notify" attributes. Sometimes the only > option left is > resorting to telephone calls, regardless of the expenses, > time differences > and language barriers often involved. The argument against making the email attribute mandatory has always been the bootstrapping problem... In the olden days (defined by my children as "when Daddy was young") it was genuinely possible for a person in the RIPE database to not actually have an email address during the setting up phase of a LIR. I would however agree with Thor, that this circumstance no longer exists. Anyone can get a temporary email address, hotmail via the local cybercafe, if nothing else, to tide them over the bootstrapping period. > > I would therefore like to suggest making the "e-mail" > attribute mandatory > for the "person" object. If this isn't acceptable, then maybe > at least one > of the "person" or "role" objects referred to by an "inetnum" > object should > carry an "e-mail" attribute. Additionally, in order to enhance address > validity, I would like to suggest performing some kind of > validation on > these "e-mail" attribute values - perhaps simple syntax > checking, or maybe > even full round-trip SMTP testing, or something in between. > > Your comments, please. > > Thor ********************************************************************** 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. 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. **********************************************************************

1 0

Change of Country entries in the database
by Christoph Mohr 23 Oct '03

23 Oct '03

Dear colleagues of the RIPE NCC database group! I'm using the RIPE whois database in its bulk version ripe.db.inetnum for statistical uses while evaluating the netflow data of our border routers. What I'm much interested in is the origin of an IP address which I get by the country entry of the respective inetnum block of the database. Therefore, I'm always a bit confused about the many addresses which are located in the Netherlands. Since I prefer large inetnum blocks for reasons of performance of my software, I often use entries of many C blocks which are registered for the RIPE NCC with the country entry NL. In the meantime, I already corrected the country entries of some inetnums in my own local copy of the database but this is just a workaround which isn't really satisfying. So I would like to suggest the change of the country entry of - at least - the following inetnum blocks (only inetnum, netname and country entries): inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK country: NL proposed country: EU # Country is really world wide inetnum: 10.0.0.0 - 10.255.255.255 netname: IANA-ABLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 145.224.0.0 - 145.254.255.255 netname: RIPE-NCC-145 country: NL proposed country: EU # Country is really world wide inetnum: 145.0.0.0 - 145.127.255.255 netname: RIPE-NL country: NL proposed country: EU inetnum: 147.233.0.0 - 147.237.255.255 netname: RIPE-ISRAELB-NET country: NL proposed country: EU [or IL] inetnum: 149.132.0.0 - 149.134.255.255 netname: RIPE-149-BLK country: NL proposed country: EU inetnum: 149.202.0.0 - 149.204.255.255 netname: RIPE-149-202-BLK country: NL proposed country: EU inetnum: 149.221.0.0 - 149.250.255.255 netname: EU-ZZ-990225 country: NL proposed country: DE inetnum: 149.206.0.0 - 149.251.255.255 netname: RIPE-149-206-BLK country: NL proposed country: EU inetnum: 163.156.0.0 - 163.175.255.255 netname: NETBLK-RIPE-B country: NL proposed country: EU inetnum: 164.128.0.0 - 164.143.255.255 netname: NETBLK-RIPE-B-128 country: NL proposed country: EU inetnum: 164.0.0.0 - 164.40.255.255 netname: RIPE-164-BLK country: NL proposed country: EU inetnum: 172.16.0.0 - 172.31.255.255 netname: IANA-BBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 192.168.0.0 - 192.168.255.255 netname: IANA-CBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide With the entry 'EU # Country is really world wide' I'm referring to an invention of the RIPE NCC due to the ERX project. You created in 2003 the following inetnums: inetnum: 141.0.0.0 - 141.255.255.255 netname: EU-ZZ-141 country: EU # Country is really world wide inetnum: 151.0.0.0 - 151.255.255.255 netname: EU-ZZ-151 country: EU # Country is really world wide inetnum: 188.0.0.0 - 188.255.255.255 netname: EU-ZZ-188 country: EU # Country is really world wide Better would be nevertheless the creation of let's say 'ZZ' or 'WW' for worldwide use, but if you put in exactly 'EU # Country is really world wide', this will be easily been parsed by Perl. I think that this is a good solution, since it doesn't make sense to put in NL for the whole IPv4 address space for example or for let's say RIPE-ISRAELB-NET. The fact that anybody in the Netherlands has to deal with the related range is clearly reflected by the contact persons or roles which is CREW-RIPE or something like that and which is situated in NL. I'm looking forward to hear your opinion. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----

11 16

Prototype release of RPSLng IRRToolSet
by Katie Petrusha 23 Oct '03

23 Oct '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.1 prototype release of IRRToolSet. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. The prototype of IRRToolSet implements the Internet Draft Document draft-blunk-rpslng-01 (http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt). The prototype release contains peval, rpslcheck and RtConfig that already work with a new dictionary (you can also try the Web prototype for peval and RtConfig). Currently work is in progess to make other tools RPSLng compatible. More details can be found at: http://www.ripe.net/db/irrtoolset Please contact irrtoolset(a)ripe.net for any comments. -- Best regards, Katie Petrusha RIPE NCC

1 0

Re: [db-wg] Change of Country entries in the database
by Wilfried Woeber, UniVie/ACOnet 23 Oct '03

23 Oct '03

Leo, >Hank Nussbacher <hank(a)att.net.il> wrote: > >[...] > >>I wouldn't make it optional > >What is the benefit of having it as a mandatory attribute? > >Regards, I can't see any at first glance (rather stuff being optional tends to get omitted anyway :-) > >-- >leo vegoda >RIPE NCC >Registration Services Manager My admin question would be: is there any internal machinery @ the NCC which assumes the presence (and "correctness") of that attribute? Wilfried.

1 0

Re: [db-wg] Change of Country entries in the database
by Hank Nussbacher 10 Oct '03

10 Oct '03

At 11:26 AM 09-10-03 +0200, Peter Koch wrote: >Hank Nussbacher wrote: > > > PS I think the country code should 00 for whole world since as countries > > split - who knows if ZZ or any two letters will be used in the future. > >ZZ is fine. ISO 3166-1 has reserved code points for exactly this purpose. >See >http://www.iso.ch/iso/en/prods-services/iso3166ma/10faq/frequently-asked-qu… Ya learn something new every day. Thanks, -Hank >"EU" is not on this list, but it's on a - meanwhile non-public - separate list >and will not be assigned. Different topic :-) > >-Peter

4 3

Fw: FAILED:
by benhadjira 06 Oct '03

06 Oct '03

Dear sir We have tried several times to add inetnum to the data-base, but unfortunetely this is the error message we received every time . Could you please give us some help & advices on how to do it ? Thanking you in advance Mourad Techni-communication -------Original Message------- From: ripe-dbm(a)ripe.net Date: samedi 4 octobre 2003 10:34:28 To: benhadjira(a)techni-communication.com Subject: FAILED: > From: benhadjira(a)techni-communication.com > Subject: > Date: Sat, 04 Oct 2003 05:34:19 -0400 > Reply-To: benhadjira(a)techni-communication.com > Message-ID: <04df532f66b14c6c874ce4e412db3b3d(a)techni-communication.com> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [inetnum] 217.29.219.0 - 217.29.219.255 ***Error: Authorisation failed ***Info: Syntax check passed inetnum: 217.29.219.0 - 217.29.219.255 netname: Techni-communication descr: Techni-Communication - customer SEI.NET country: DZ admin-c: MA1973-ripe tech-c: BM1974-RIPE status: LIR-PARTITIONED PA mnt-by: BM-MNT mnt-lower: BM-MNT mnt-routes: TACHYON-EU-MNT changed: benhadjira(a)techni-communication.com 20031004 source: RIPE ***Info: Authorisation for parent [inetnum] 217.29.208.0 - 217.29.223.255 using mnt-lower: not authenticated by: BM-MNT ***Info: Authorisation for [inetnum] 217.29.219.0 - 217.29.219.255 using mnt-by: not authenticated by: BM-MNT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following paragraph(s) do not look like objects and were NOT PROCESSED: -------------------------------------------------------------------- mail2web.com - Check your email from the web at http://mail2web.com. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net> .

2 1

Reverse DNS Restructuring Project
by Olaf M. Kolkman 01 Oct '03

01 Oct '03

Dear Colleagues, I have just posted a proposal about the restructuring of the reverse DNS setup to the ncc-services-wg mailing list. I'd like to point out that this proposal has relevance to both the dns-wg and db-wg. You can find the proposal on http://www.ripe.net/reverse/proposal.html Please provide your feedback on the ncc-services-wg mailing list. With excuses for the cross-post, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Looking for good way to find blocks allocated directly by ripe
by william＠elan.net 27 Sep '03

27 Sep '03

Hi, I'd like to find what is the best way to determine if particular inetnum was allocated directly by RIPE, this would include all blocks allocated to LIRs, all blocks allocated to large organizations and blocks allocated as small PI blocks. Currently I have come with the following way to do it - first find all inetnum objects listed as "ALLOCATED PI" with network name starting as "EU-ZZ", this find all PI space; then discard all "ASSIGNED PA" blocks except those within range of previously found "ALLOCATED PI" blocks and also discard "ALLOCATED PI" and "LIR-PARTITIONED PA" blocks. >From reminder the netblocks totally within another inetnum are discarded as well as "superblocks" listed under RIPE name. I'd like to find if you think doing it this way would leave any blocks out or include too many larger block then direct RIPE allocations. Doing it the way I described above, already produced some data available at http://www.completewhois.com/bogons/data/allocated-cidr-ripe_main.txt and non-allocated space is at http://www.completewhois.com/bogons/data/bogons-cidr-ripe_main.txt I'd like to verify validity of this data and the process I used, especially considering that I see number of errors, for example there are several blocks > /24 listed as allocated (but I did not think RIPE did any direct allocations or assignemsns of size > /24), for example: 193.58.0.64/26 193.164.232.192/26 193.201.147.0/26 193.201.148.64/26 193.243.183.0/26 193.254.0.64/26 194.1.127.128/26 194.9.166.0/26 194.149.71.128/26 194.153.156.0/26 194.180.159.128/26 194.180.226.192/26 194.246.39.0/26 194.246.39.128/26 195.35.104.64/26 -- William Leibzon Elan Networks william(a)elan.net

3 3

Organisation Object Proposal, version 3
by DB-News 22 Sep '03

22 Sep '03

Dear Colleagues, [apologies for duplicate messages] After the discussions we had in the RIPE 46 Meeting and in the WG mailing lists, we have incorporated agreed modifications into organisation object proposal, which you can find below. This is the Version 3 of the proposal. You can find the first version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html and a summary of discussions on the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00213.html Thank you very much for your input on the issue. Best regards, -- Engin Gunduz RIPE NCC Database Group ============================================================ An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other objects using an "org:" attribute. All objects associated with a particular organisation ID can be retrieved by performing an "inverse query" for this ID used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "mnt-ref:", "organisation:", "org-name:", "org-type:" and "org:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. "mnt-ref:" Specifies the maintainer objects that are entitled to add references to the organisation object from other objects. "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any object type. It points to an existing organisation object representing the entity that holds the resource, in the cases where the whois DB object represents an Internet resource. In other objects, it can be used to specify the business relations. The value of this attribute is the ID of the organisation object. It is mandatory in the inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects. "org:" attribute is single-valued in the inetnum, inet6num and aut-num objects, and it is multi-valued all other objects. The "org:" attribute is used to specify the holder of a resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in them. In other objects, it specifies business relations (like in a person object, where it can be used to specify whom the person works for) it can be multiple (in the person object example, a person might work for several companies). 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers in the "mnt-ref:" attributes of the organisation object - from one of the maintainers in the "mnt-by:" attributes of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-ref: EXAMPLE-MNT mnt-by: EXAMPLE-MNT changed: someguy(a)example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy(a)example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE

1 0