- db-wg - mailman.ripe.net

Re: Migration issues: route creation
by Andrew Hilborne 13 Feb '01

13 Feb '01

"Lu, Ping" <plu(a)cw.net> writes: > ... > We have already seen some of the global issues showed up in the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? Or SNMP? Andrew Hilborne

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm(a)ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

RE: Migration issues: route creation
by Lu, Ping 13 Feb '01

13 Feb '01

I think that's me :) Let's talk about the GLOBAL issues and the practical use of RR. For all RIRs like RIPE, ARIN, APNIC and so on. They are in a regulartory position so they OWN all the objects (AN, PN, MT) and they seldom need to CROSS-REFERENCE with other RIRs. So the self-contained assumption (all references should be resloved locally ) is fine with RIR. But for the LIRs (especially the ISPs) RR has a more practical use, like auto-generated access-lists and as-path filters. Almost all the major ISPs have their own tools or use the public tool like RAToolSet to pull data from RR then auto-generate the configiuration for their routers. Now here is the fun part. As a global player we have to create a list of objects ( AN, RT ) from all the RIRs and with any public peer (registered in one of the RIRs ) we have to create a list of rather private objects ( MT, PN, RO ). But it becomes too difficult to duplicate those private objects with up-to-date information, so the best way is to REFERENCE their LEGAL objects in any one of the RIRs ( of course if the AS itself agree us to do so ). This is where the GLOBALLY UNIQUE nic-hdl comes in and in a more generic sense, how about GLOBALLY UNIQUE maintainer name ? Does this sound like domain name system ? Sooner or later RR has to face the GLOBAL issue like DNS, IP address and E-MAIL did. We have already seen some of the global issues showed up in the RR domain ( referral, globally unique nic-hdl ) and there will be more and more name-collision in the future. So why not adopt a naming system like DNS or E-MAIL ? Here is my favorite quote from RFC2622 ----------------------------------------------------- <nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information. ----------------------------------------------------- Hmmm! So RPSL already specify the need to use information from OTHER REGISTRIES. I rest my case. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Monday, February 12, 2001 7:32 PM > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Migration issues: route creation > > > Dear Andrei, > > you wrote that there will be problems creating duplicates of > aut-nums and > routes in other registries if they do not formally belong > there due to the > authorization rules introduced with the RPSL transition at RIPE. You > suggested two solutions: > > > Possible solutions to this problem are: > > > > 1. Send such registration requests to the Database Administration > > (ripe-dbm) who will perform registration by overriding > security (and > > performing necessary checks before). This puts additional load on > > ripe-dbm and creates duplicate objects in the RIPE database and > > "foreign" IRR. > > > > 2. Do not allow such registrations. In this case some ISPs > will need to > > change their peering policy and accept routing information from a > > "foreign" IRR. > > > > Your comments and suggestions are highly appreciated. > > > I did not yet see an answer to your question. However, I > believe that your > first suggestion should *not* be followed. I definitely would > want to avoid > opening "side" paths to enter data into the RIPE database. > Using ripe-dbm > should be the exception for special requirements. For > everything else, the > robots should be used. > > Regarding duplication: this had originally been introduced to > help people > along while mirroring was not working. With RIPE having > transitioned to RPSL, > we will have compatible formats again, and do not need > duplication anymore - > under the prerequisite that you are properly coordinating > with RADB and any > other major IRR. I am inclined to say, that avoiding > duplication is the > purpose of the effort! > > Looking at your second proposal, I believe that you are > saying the right > thing, but phrased it a little different. Peering policy is > probably a term > which may be confused with routing policy - and nobody needs > to change its > routing policy by looking at several IRRs now. Actually, I > believe that there > is not much of an issue: Smaller ISPs have always registered > in only one IRR; > only bigger providers with international reach have entered > their information > into several IRRs and duplicated data, but then also using > data from all IRRs > they registered into. It should not be too much of a pain to use this > information to continue with this practice after the RPSL transition. > > Those parties who do not agree, speak up loudly now! > Thanks > Joachim > > --- JS395-RIPE -- standard disclaimer --- >

1 0

Re: Migration issues: route creation
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

Dear Andrei, you wrote that there will be problems creating duplicates of aut-nums and routes in other registries if they do not formally belong there due to the authorization rules introduced with the RPSL transition at RIPE. You suggested two solutions: > Possible solutions to this problem are: > > 1. Send such registration requests to the Database Administration > (ripe-dbm) who will perform registration by overriding security (and > performing necessary checks before). This puts additional load on > ripe-dbm and creates duplicate objects in the RIPE database and > "foreign" IRR. > > 2. Do not allow such registrations. In this case some ISPs will need to > change their peering policy and accept routing information from a > "foreign" IRR. > > Your comments and suggestions are highly appreciated. > I did not yet see an answer to your question. However, I believe that your first suggestion should *not* be followed. I definitely would want to avoid opening "side" paths to enter data into the RIPE database. Using ripe-dbm should be the exception for special requirements. For everything else, the robots should be used. Regarding duplication: this had originally been introduced to help people along while mirroring was not working. With RIPE having transitioned to RPSL, we will have compatible formats again, and do not need duplication anymore - under the prerequisite that you are properly coordinating with RADB and any other major IRR. I am inclined to say, that avoiding duplication is the purpose of the effort! Looking at your second proposal, I believe that you are saying the right thing, but phrased it a little different. Peering policy is probably a term which may be confused with routing policy - and nobody needs to change its routing policy by looking at several IRRs now. Actually, I believe that there is not much of an issue: Smaller ISPs have always registered in only one IRR; only bigger providers with international reach have entered their information into several IRRs and duplicated data, but then also using data from all IRRs they registered into. It should not be too much of a pain to use this information to continue with this practice after the RPSL transition. Those parties who do not agree, speak up loudly now! Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

problems with complex import/export attributes
by Frank Bohnsack 12 Feb '01

12 Feb '01

Hi, Yes, I know this is not a RPSL forum, but i think someone of you could help me ;-) I found a problem for RPSL parsers conform with RFC2622. In the RFC2622 (section 6.6) is an example of an import attribute: > import: from AS1 action pref = 1; accept as-foo; > except { > from AS2 action pref = 2; accept AS226; > except { > from AS3 action pref = 3; accept {128.9.0.0/16}; > } > } Appendix B "Grammar Rules" describes the syntax like below: > ... > import_attribute: ATTR_IMPORT > | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor > > import_expression: import_term > | import_term KEYW_REFINE import_expression > | import_term KEYW_EXCEPT import_expression > > import_term: import_factor ';' > | '{' import_factor_list '}' > > import_factor_list: import_factor ';' > | import_factor_list import_factor ';' > > import_factor: import_peering_action_list KEYW_ACCEPT filter > > import_peering_action_list: KEYW_FROM peering opt_action > | import_peering_action_list KEYW_FROM peering opt_action > > ... I feel in import_attribute lakes a line like: | ATTR_IMPORT opt_protocol_from opt_protocol_into import_expression and a look into ftp://ftp.isi.edu/ra/RAToolSet/RAToolSet-4.6.3.tar.gz file src/rpsl/rpsl/rpsl.y agree with me: > ... > import_attribute: ATTR_IMPORT > opt_protocol_from opt_protocol_into > import_expr TKN_EOA { > $$ = changeCurrentAttr(new AttrImport($2, $3, $4)); > } > | ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor TKN_EOA { > PolicyTerm *term = new PolicyTerm; > term->append($4); > > $$ = changeCurrentAttr(new AttrImport($2, $3, term)); > } > | ATTR_IMPORT error TKN_EOA { > $$ = $1; > handle_error("Error: from <peering> expected.\n"); > yyerrok; > } > ; > .. OK as so far, but rpslcheck as well as my perl parser module breaks while parsing the example above ;-( > fb@sun5 1315> rpslcheck < example > ... > import: from AS1 action pref = 1; > accept as-foo; > except { > from AS2 action pref = 2; accept AS226; > except { > ^^^^^^ > ***Error: from <peering> expected. > from AS3 action pref = 3; accept {128.9.0.0/16}; > } > } > ... For me looks the grammar correct, but my knowledge about automata theory, languages and computation is worser than my english ;-) Has anybody a solution for this problem ? cheers frank

2 1

Re: Modifying 'person:' objects
by Carsten Schiefner 11 Feb '01

11 Feb '01

So, how to proceed here now? Can we agree on the follwoing: A 'force:' attribute for changing the 'person:' attribute itself shall be allowed if and only if the person or role object is maintained and the maintainer uses "strong" protection, such as 'password' or 'PGP'. Already appreciating your comments, Carsten -------- Original Message -------- Subject: Modifying 'person:' objects Date: Mon, 29 Jan 2001 14:02:47 +0100 From: Carsten Schiefner <carsten.schiefner(a)tcpip-gmbh.de> To: db-wg(a)ripe.net Colleagues, as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list. What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data changed manually. I consider this as not very efficient. During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma. What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...). Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so... Any comments will be appreciated. Best regards, -C.

1 0

Software engineer position at RIPE NCC
by Andrei Robachevsky 08 Feb '01

08 Feb '01

Dear Colleagues, This is to inform you that the RIPE NCC has a vacancy for a Database Software Engineer. If you are interested, please visit our web site for more information: http://www.ripe.net/ripencc/employment/db-softeng-feb01.html. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Performance slowdown of whois server
by RIPE Database Administration 08 Feb '01

08 Feb '01

Dear colleagues, Currently we are experiencing a performance slowdown on our whois server, thus, the server takes more time than usual to reply queries. We are investigating the issue and will take appropriate measures ASAP. We are sorry for any inconvenience. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Planned maintenance
by RIPE Database Administration 07 Feb '01

07 Feb '01

Dear colleagues, To improve the quality of our service, we decided to report on reindexing of our database, and other maintenance issues. We will continue to do this if the community thinks this is a good idea. Next weekend, 10-11 February 2001, RIPE NCC will reindex the person objects in RIPE whois database. This is a usual maintenance practice, performed once every three weeks. The reindexing will start at 2:00am Saturday, and is expected to last around 40 hours, due to the very high number of person objects in our database. During the reindexing, it won't be possible to update, delete, or create person objects. The messages containing person objects will be queued. Any person object in an update message to <auto-dbm(a)ripe.net> will cause the whole update message to be blocked until the reindexing process finishes. Thus, we suggest our users not to put person objects in a message that contains other types of objects. Reindexing will not be needed in version 3 of our database software. You can see a schedule for this and other maintainance issues at: http://www.ripe.net/ripencc/pub-services/db/DBstatus.html This page will be updated regularly. We apologize for any inconvenience the maintenance may cause. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Modifying 'person:' objects
by Carsten Schiefner 05 Feb '01

05 Feb '01

Colleagues, as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list. What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data changed manually. I consider this as not very efficient. During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma. What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...). Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so... Any comments will be appreciated. Best regards, -C.

3 3

RE: Modifying 'person:' objects
by Wilfried Woeber, UniVie/ACOnet 05 Feb '01

05 Feb '01

>Are you proposing to change the RIPE-181 version of RIPE-DB software >(v2.x) or the upcoming RPSL version of RIPE-DB software (v3.x) ? Based on - the fact that handling of person: and role: objects is not going to change too much due to RPSL or DB-SW V3, and - the fact that we have agreed on "DateX" to be April 23, 2001, and we still have to discuss the merits of Karsten's proposal, I think the implementation would only affect Version 3. Regards, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Migration issues: route creation
by Andrei Robachevsky 05 Feb '01

05 Feb '01

Dear Colleagues, You may know that the new version of the RIPE database (v3.0) also supports Routing Policy Security System (RFC2725). One of the implications is that this may prevent registrations of "foreign" routes in the RIPE IRR (that is routes from non RIPE address space and/or non RIPE ASN). According to RFC2725, creation of a route object should be authorized by the "owner" of the respective address space or aggregate route and by the "owner" of the ASN that is specified as route origin. In case of absence of the corresponding objects, creation of the route object will fail. The creation of the corresponding "foreign" objects will not be as easy in the new version as it is in the current one. The ASN space will be protected by as-block object, and IP address space by corresponding top level inetnum object. This makes registration of "foreign" routes almost impossible, which affects current practice when an IPS requests that clients' routes should be registered in the RIPE IRR. Possible solutions to this problem are: 1. Send such registration requests to the Database Administration (ripe-dbm) who will perform registration by overriding security (and performing necessary checks before). This puts additional load on ripe-dbm and creates duplicate objects in the RIPE database and "foreign" IRR. 2. Do not allow such registrations. In this case some ISPs will need to change their peering policy and accept routing information from a "foreign" IRR. Your comments and suggestions are highly appreciated. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: Modifying 'person:' objects
by Lu, Ping 30 Jan '01

30 Jan '01

Are you proposing to change the RIPE-181 version of RIPE-DB software (v2.x) or the upcoming RPSL version of RIPE-DB software (v3.x) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Carsten Schiefner [mailto:carsten.schiefner@tcpip-gmbh.de] > Sent: Monday, January 29, 2001 8:03 AM > To: db-wg(a)ripe.net > Subject: Modifying 'person:' objects > > > Colleagues, > > as a follow-up of the short discussion we have had last week > during RIPE > 38 I'd like to continue this discussion in the appropriate forum, the > db-wg mailing list. > > What from time to time really annoys me is the fact that you cannot > change a person's name (necessary due to misspellings etc.) that is > already referenced because the person's name together with the NIC > handle is the primary key. You cannot delete and re-enter it either > because it's already referenced. The only way to go is to > send an email > to the human db processor ;-) 'ripe-dbm(a)ripe.net' to get the data > changed manually. I consider this as not very efficient. > > During the meeting we were told by Joao and/or Andrej that basically > there is no further need to have person's name _AND_ NIC handle as the > primary key, only the NIC handle would be enough. Anyhow, I wouldn't > like to touch this pragma. > > What I would like to propose is a second "pseudo" attribute > in addition > to 'delete:' - having no documentation purpose but functionality: the > "I really know what I am doing right at the moment" attribute > ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above > mentioned db pragma and forces a change in a person's name > (so 'force:' > migt be better...). > > Where I haven't made up my mind yet is the question whether > this always > should apply or only in thoses cases when a person object is > maintainer > protected. There might be further cases I have not in mind at > all at the > moment - so... > > Any comments will be appreciated. > > Best regards, > > -C. > > >

1 0

CERT/IRT object in the RIPE database
by Gorazd Bozic 23 Jan '01

23 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Dear RIPE DB-WG team, I would like to inform you that the proposal for the CERT/IRT object in the RIPE database was presented by Wilfried Woeber at the TERENA TF-CSIRT meeting last Wednesday in Barcelona. After a discussion and proposed minor changes, the participants at the meeting expressed their strong support for the proposed new object. The purpose of the TERENA CSIRT Coordination activity in the frame of TF-CSIRT is to encourage and support the cooperation between CSIRTs in Europe. More information on TF-CSIRT is available at http://www.terena.nl/cert/ Best regards, Gorazd Bozic, TF-CSIRT Chairman - -- Gorazd Bozic <gorazd.bozic(a)arnes.si> ARNES SI-CERT, Jamova 39 p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 88 22, fax: +386 1 479 88 99 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOmt2mwxzg1x3uI5pAQGicgQA6EBqi2jrONkYYFEHDAilLTcUbvZ13EUj DXRUG6wR4S0avygROM8WhYu63U08tAkQ8NUUv+rPXof/jToMNHqLiFx05bTgnRcK 53Dsue+m/XWxA1/IO6ju9Ldr1b1HKzxaDXpikiEsG7y+iR3ghhMaWH4py7xmzube XgI/RGFeHoA= =9Lv9 -----END PGP SIGNATURE-----

3 2

Delays in RIPE Database updates
by RIPE Database Administration 22 Jan '01

22 Jan '01

Dear All, As some of you may have already noted, we are experiencing delays with the processing of updates in the RIPE Database. This is due to the fact that the last week-end, the reindexing of person objects took much longer than expected; in the meanwhile, no updates could be processed, so they remained blocked in the queue. As of now, the updates are being regularly processed. We want to stress the fact that your updates will be eventually processed and there is no need to resend your update messages; this will have the sole effect of adding load to the update queue. To check the current wait time for updates and other operational statistics for the RIPE Whois Database server, please see: http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html We apologize for any inconvenience this may cause or have caused. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

URGENT: Database problems?
by Berislav Todorovic 21 Jan '01

21 Jan '01

Dear RIPE NCC colleagues, I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, but can someone, please, take a look on the database update queue? Either the queue is full or the automatic email robot is broken. We sent an update of AS-KPNQWESTRO few times since Friday and no answer we got from the robot. That's 3 (three) days !!!!!!!!! Thanks! Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

2 1

Announcement: RIPE Whois Database Version 3.0beta2 released
by RIPE Database Announcements 19 Jan '01

19 Jan '01

Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact <ripe-dbm(a)ripe.net> for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC

3 2

DB-WG minutes
by Nigel Titley 19 Jan '01

19 Jan '01

Here is the final version of the DB-WG minutes. I have rolled in all comments received to date. Nigel

1 0

RPSL question
by Frank Bohnsack 18 Jan '01

18 Jan '01

Dear Colleague, I'm writting a Perl RPSL parser module and have a understanding problem with part 2 "RPSL Names, Reserved Words, and Representation" page 5 of RFC 2622 ;-( "A value of an attribute may also be a list of one of these types. A list is represented by separating the list members by commas ",". For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note that being list valued and being multiple valued are orthogonal. A multiple valued attribute has more than one value, each of which may or may not be a list. On the other hand a single valued attribute may have a list value." Ok, a multiple attribute value can be a single value or a 'comma list' of values. But the last sentence confused me - "a single valued attribute may have a list value" ? Means that "aut-num: AS123, AS456, ..." is a correct attribute of an aut-num object ?!?! Cheers Frank

3 2

RE: Loop in AS macro
by Lu, Ping 18 Jan '01

18 Jan '01

Hi, Shane, Thank for the tip. It works. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Thursday, January 11, 2001 4:46 AM > To: Lu, Ping > Cc: 'cengiz(a)packetdesign.com'; Wilfried Woeber, UniVie/ACOnet; > farrache(a)cc.in2p3.fr; db-wg(a)ripe.net; routing-wg(a)ripe.net; > Henk.Uijterwaal(a)ripe.net > Subject: RE: Loop in AS macro > > > Ping, > > What I usually do (in Perl) is something like this: > > my %entries_seen; > foreach my $as_set (@as_sets) { > # if we've seen this value (recursive as-set), skip > next if ($entries_seen{$as_set}); > > # note that we've seen this as-set > $entries_seen{$as_set}++; > > # get a list of members of the as-set, and process appropriately > foreach my $member (members($as_set)) { > # add member as-sets to the list of as-sets to process > push(@as_sets, $member) if ($member =~ /^AS-/i); > > # other processing here > . > . > . > } > } > > If you're using some other scripting language, it will be > different, but > typically no more difficult. If you're in C, you may want to > use glib or > something like that, otherwise you'll need to use a list or > hash you write > yourself. > > Shane Kerr <shane(a)ripe.net> > Database Software Engineer > RIPE NCC > +31 20 535 4427 > > On Wed, 10 Jan 2001, Lu, Ping wrote: > > > Hi, I am new to this list and would like to ask a (maybe > stupid) question to > > the dicussion: > > > > If we want to write a script to expand the AS MACRO, how > can we avoid to go > > into a loop if multiple AS-MACROs reference each other ? > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: 703-292-2359 > > E: plu(a)cw.net > > > > > -----Original Message----- > > > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > > > Sent: Wednesday, January 10, 2001 12:14 PM > > > To: Shane Kerr > > > Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; > > > db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net > > > Subject: RE: Loop in AS macro > > > > > > > > > > > > Shane Kerr (shane(a)ripe.net) on January 10: > > > > Gilles, Wilfried, and all, > > > > > > > > This is not a bug, or even an inconsistency. Consider > the following > > > > as-macro objects: > > > > > > > > as-macro: AS-X > > > > members: AS-Y, AS123 > > > > > > > > as-macro: AS-Y > > > > members: AS-X, AS456, AS789 > > > > > > > > In this case, AS-X and AS-Y both expand to the same > aut-num objects: > > > > AS123, AS456, and AS789. However, they may have different > > > maintainers, > > > > contacts, descriptions, and so on. In RPSL, many more > > > kinds of loops are > > > > possible as well, in as-set, route-set, and filter-set objects. > > > > > > RPSL defines semantics when loops exist. However, it does > not promote > > > them, or prohibit additional restrictions by the registry > operators > > > not to have loops. > > > > > > > > > > > External software that deals with the set objects needs > to do loop > > > > detection in order to prevent infinite loops. For as-set > > > objects (which > > > > are as-macro objects in RIPE-181), this is fairly easy: > > > keep a list or > > > > hash of the AS sets expanded, and don't expand them again. > > > For route-set > > > > and filter-set objects it is not quite so easy. If you > > > need help with > > > > these, you can send me and e-mail and I can explain the > > > techniques that > > > > I've used for these objects. > > > > > > > > Shane Kerr <shane(a)ripe.net> > > > > Database Software Engineer > > > > RIPE NCC > > > > +31 20 535 4427 > > > > > > > > p.s. This is actually a feature, not an bug. :) > > > > > > > > p.p.s. It has been argued (by me) that RPSL allows > objects that are > > > > logically impossible, but the RFC authors don't seem to > think so! > > > > > > > > On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > > > > > Hi Gilles, > > > > > > > > > > I guess we wouldn't be able to check against those > > > accidents at the time > > > > > of a DB _update_... > > > > > > > > > > But checking the RR internal _data_ consistency could > > > maybe become part > > > > > of the RIS (or similar) project? > > > > > > > > > > Henk, any comments? > > > > > > > > > > An interesting aside: I guess similar problems > could occur with > > > > > RPSL-based RRs? > > > > > > > > > > -WW > > > > > > > > _________________________________:____________________________ > > > _________ > > > > > Wilfried Woeber : e-mail: > Woeber(a)CC.UniVie.ac.at > > > > > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > > > > > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > > > > > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP > > > keyID 0xF0ACB369 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > ~~~~~~~~~ > > > > > > > > > > To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, > > > admin-c(a)tli.de > > > > > CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net > > > > > Subject: Loop in AS macro > > > > > Date: Wed, 10 Jan 2001 10:28:15 +0100 > > > > > From: Gilles Farrache <farrache(a)cc.in2p3.fr> > > > > > > > > > > Dear database managers, > > > > > > > > > > I notice a loop in the followings AS-MACRO, in fact > > > AS-TELEDANMARKINTERNATIONAL > > > > > is calling AS-TLI which is calling AS-TELEDK which is > > > calling AS-TELEDANMARKINTERNATIONAL. > > > > > (and all that make that our automatic filter generation > > > tool fails) > > > > > > > > > > Could you correct those macro and will the Ripe database > > > management provide any > > > > > control on that kind of loop ? > > > > > > > > > > Gilles > > > > > > > > > > as-macro: AS-TELEDANMARKINTERNATIONAL > > > > > descr: Tele Danmark customers outside Denmark > > > > > as-list: AS1902 AS12461 > > > > > as-list: AS8881 AS-KOMTEL > > > > > as-list: AS13194 AS-BITE > > > > > as-list: AS6709 > > > > > as-list: AS8650 AS-TLI > > > > > as-list: AS8542 > > > > > as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 > > > AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 > > > > > as-list: AS12546 > > > > > as-list: AS15389 > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 20001103 > > > > > changed: toba(a)tdk.dk 20001117 > > > > > changed: tee(a)tdk.dk 20001123 > > > > > changed: jesper(a)skriver.dk 20001228 > > > > > changed: jesper(a)skriver.dk 20010109 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TLI > > > > > descr: Talkline GmbH, Internet Division > > > > > descr: List of ASes according to Talkline > Internet (AS8650) > > > > > descr: and customers > > > > > as-list: AS5605 > > > > > as-list: AS6783 > > > > > as-list: AS8650 > > > > > as-list: AS8881 > > > > > as-list: AS12461 > > > > > as-list: AS12546 > > > > > as-list: AS-TELEDK > > > > > as-list: AS-GLOBAL > > > > > tech-c: TLIP1-RIPE > > > > > admin-c: TLIP1-RIPE > > > > > notify: peering(a)tli.de > > > > > mnt-by: TALKLINE-MNT > > > > > changed: thomas(a)tli.de 19990923 > > > > > changed: thomas(a)tli.de 19991020 > > > > > changed: thomas(a)tli.de 19991025 > > > > > changed: thomas(a)tli.de 20001023 > > > > > changed: thomas(a)tli.de 20001025 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TELEDK > > > > > descr: Tele Danmark and Tele Danmark customers > > > > > as-list: AS-TELEDANMARKDANISH > > > > > as-list: AS-TELEDANMARKINTERNATIONAL > > > > > as-list: AS-BELBONEMEMBERS > > > > > as-list: AS-GLOBAL > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 19990922 > > > > > changed: jesper(a)skriver.dk 19991019 > > > > > changed: jesper(a)skriver.dk 19991025 > > > > > changed: jesper(a)skriver.dk 19991210 > > > > > changed: toba(a)tdk.dk 20000903 > > > > > source: RIPE > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > > > > > > > > > > > > > > > > Cengiz > > > > > > -- > > > Cengiz Alaettinoglu Packet Design Inc. > > > > > > > > >

1 0

Re: CERT Object summary (for review in Paris)
by Wilfried Woeber, UniVie/ACOnet 17 Jan '01

17 Jan '01

Below please find the most recent summary of our proposal for a "CERT Object", taking into account all the comments I am aware of - as well as a couple of proposals for clarifiaction and open issues. This is for discussion and review by CERTs/IRTs in Barcelona and input for the DB-WG meeting next week in Amsterdam. Attributes that are "DB-Standard" get no tag, the CERT Object specific attributes are tagged with "*". For the description of the "DB-Standard" attributes refer to the DB Software documentation, please. * irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [ ] auth: [mandatory] [multiple] [ ] * mnt-cert: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] * signature: [mandatory] [multiple] [] * encryption: [mandatory] [single] [] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] - The irt: attribute assigns a unique name to an IRT object. Q: [to the NCC DB group] in your example, the IRT: attribute's value looks like a handle, and it is used like a handle in references. Wouldn't it be "cleaner" to allow person: and role: like identifications and assign a handle, which is then used to as a reference? Q: Another issue: assuming that a similar facility becomes available in other registry databases, should we try to "reserve" a handle-suffix for those handles? The use of "RIPE-CERT" got me wondering... - The mnt-cert: attribute points to a key-cert: object; it is checked when this irt object is added to e.g. an inetnum:. For all objects that support a pointer to an irt: object, a new attribute is defined as a reference pointing to an irt: object. This attribute might be named irt-c: or incident-c: Q: from an end-user point of view, wouldn't it be more "obvious" to use abuse-c: ? Q: We said that as a value for the auth: attribute, only PGPKEY-<key-id> would be allowed. Do we really need both, the (restricted) auth: _and_ the mnt-cert: ? - The signature: attribute points to a key-cert: object which defines one or more keys that are user by the CERT's team members to sign and/or encrypt messages sent by the team. - The encryption: attribute points to a key-cert: object which defines the key that should be used to sign and/or encrypt messages sent to the team. Q: should we try to find a more "obvious" name for those tags? I could think of sig-from: and encrypt-to: (similar to SMTP mail from and rcpt to :-) or even from-irt: and to-irt: Wilfried.

2 1

Re: Minutes from San Diego
by Randy Bush 17 Jan '01

17 Jan '01

i could not even get into the room. the minutes say whois users RIRs, routing registries, domain registries, registrars #1 and #2 are close #3 is a bit different actually, the whois port/protocol is used by all sorts of strange and arcane uses by all sorts of folk. imiho, we do not have the prerogative to break their uses by a change to the base whois/43 protocol. this is not to say that some group of applications of the whois protocol could not agree to use it in a common way, essentially forming an overlay protocol. randy

1 0

Moving the whois protocol discussion
by Paul Hoffman / IMC 15 Jan '01

15 Jan '01

Greetings. At the San Diego IETF meeting, it was decided that there was a desire to continue the discussion of updating the whois protocol. In the BOF, the address of this list was given for the discussion. Clearly, this list has lots of discussion that is not relevant to the whois update discussion, and vice versa. Because of this, I have set up a new list just for discussing the update to the whois protocol. Subscription information for the new list can be found at <http://www.imc.org/ietf-whois/>. The list is accepting subscriptions now, and posting to the list will start tomorrow. --Paul Hoffman, Director --Internet Mail Consortium

1 0

LIR-ALLOCATED revisited
by James Aldridge 15 Jan '01

15 Jan '01

LIR and DB Working Groups (with apologies for duplicate email), Discussed at RIPE-34 but with little subsequent action, I would like to repropose the addition of LIR-ALLOCATED as a valid status value for inetnum objects in the RIPE database. Attached is a slightly revised version of the document ("troff -ms" source version available on request) I last posted a year ago as a result of LIR-WG Action LIR-34.8. The suggestion then was that this could be massaged into a RIPE document (I think dfk volunteered!) to update ripe-185 (European Internet Registry Policies and Procedures) and that support for the new value be added to the database (and NCC tools as necessary). Regards, James -- Senior Network Engineer, IP Archictecture Group, KPNQwest Singel 540, 1017 AZ Amsterdam, NL ----------cut here---------- "Status: LIR-ALLOCATED" Considered Useful James Aldridge ----- -------- This document proposes a new value for the status field of the inetnum object in the RIPE database in addition to those listed in sections 3.4.2 (PA vs PI space) and 4.4 (Allocation Registration) of the "European Internet Registry Policies and Procedures" document ripe-185. For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). -2- An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGYZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGYZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - REGY-MNT in this case. There is also a mnt- lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The final inetnum object here is a final assignment from the national organisation to a customer.

1 0

Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball (fwd)
by Wilfried Woeber, UniVie/ACOnet 15 Jan '01

15 Jan '01

Dear Andreas Jennen! >Subject: Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) > X-NCC-RegID: de.aball (fwd) >please answer my questions idown in my text ! I'll try ;-) >Will i have soon 20 hdl ? Maybe... (unless the community succeeds to get the mess sorted out again. Any help - including yours - would be appreciated ;-) >Is that, what you wanted ? Definitely: NO. For a few more comments, see below, marked "****" Regards, Wilfried (DB-WG chair) PS: and by the way, shouting at innocent people like NCC staff is not necessarily the best approach to get problems resolved in the Internet... ______________________________________________________________________ >----- Forwarded message from RIPE NCC Hostmaster ----- > >Message-Id: <200101121426.PAA15401(a)x60.ripe.net> >To: jennen(a)aball.de >Subject: Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball >In-reply-to: Your message of Fri, 05 Jan 2001 22:46:46 +0100. > <200101052146.WAA20734(a)sonne.aball.de> ><References: <200101052146.WAA20734(a)sonne.aball.de> >From: RIPE NCC Hostmaster <hostmaster(a)ripe.net> >X-Organization: RIPE Network Coordination Centre >X-Phone: +31 20 535 4444 >X-Fax: +31 20 535 4445 >Date: Fri, 12 Jan 2001 15:26:11 +0100 >Sender: hostmaster(a)ripe.net > > >Hi Andreas, > >This change was agreed by the Database Working Group. If you have a >problem with this decision please raise it on the <db-wg(a)ripe.net> >mailing list or at the working group meeting during this month's >meeting. **** This problem was already on the DB-WG Meeting during RIPE37, September 2000. It might again get put onto the DB-WG Meeting agenda **** for RIPE38, January 2000. >Sorry to have upset you - have a good weekend. > > > Regards, > > ------------------- > Geoff Charters > Ripe NCC Hostmaster > ------------------- > >"QUICK TIPS FOR REQUESTS": <http://www.ripe.net/ripencc/tips/tips.html> > > In the previous mail Andreas Jennen <jennen(a)aball.de>, wrote: > * > * from Andreas Jennen > * jennen(a)aball.de > * x-NCC-RegID: de.aball > * > * Dear hostmaster, > * > * what a hell why is this ? See below > * > * Is this correct, what *.at need ? > * > * One handle for every European contry, where i am admin of an domain ? > * > * Before i was in Europe and also USA: > * > * AJ4-RIPE > * > * now i need 20 or 30 handles ? > * > * Why is RIPE so stupid ? **** A few clariciations should be helpful here. There is . RIPE the "community", the users, some working groups run by volunteers, some eMail lists, some meetings - and there is the . RIPE NCC a service organisation with a well-defined mandate, an activity plan, and customers like the LIRs. While RIPE (the community) is discussing Internet issues in general, coming up with recommendations and consensus, this RIPE is not the "Internet Police". Nor is the RPE community authoritative for everything that is happening in CyperSpace. While RIPE (the community) is regularly interacting with the RIPE NCC (receiving support from and providing guidance to the RIPE NCC), the RIPE *NCC* is an autonmous organisation, which by consensus of the community (and not the least supported by the financial backing of it's members and customers!) is *responsible* and *authoritative* for . *IP-Adress distribution*, . ReverseDNS delegation for the relvant parts of the inverse tree, . and a couple of other things which is outlined as community service in the activita plan. The RIPE NCC (and RIPE, btw.) is NOT authoritative for any ccTLD administration issues! Indeed, for coordination issues regarding ccTLDs (mostly in Europe), another organistion was formed and has taken responsibilty (CENTR, see their info pages at http://www.centr.org/). nd CENTR is workling **** within the framework of ICANN/IANA. > * > * Whatfor we pay 2100 Euro every jear ? > * **** I guess for the services as extended by the RIPE NCC according to **** your customer and membership agreement??? > * Please also give the national domain organisation like e.g. > * Denic > * > * the order to take our full Ripe handles as nic-hdl. **** Neither the RIPE NCC, nor any of the RIPE Working Groups would have any authority to do so. The Organisations you are pointing fingers at can accept input and guidance, and usually they do, but they also have to operate according to their existing administrative, legal and financial framework, and responsibility to their constituencies. It would certainly be helpful if you could summarize your concerns **** and forward them to the relvant channels (e.g. CENTR)! > * > * e.g. > * whois -h whois.ripe.net AJ4-RIPE > * > * RIPE says: > * > * % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-servic > * es/db/copyright.html > * > * person: Andreas Jennen > * address: aball Internet Netzdienste GmbH > * address: Roscherstr. 10 > * address: D-30161 Hannover > * address: Germany > * phone: +49 511 270 737-0 > * fax-no: +49 511 69 90 91 > * e-mail: jennen(a)aball.de > * nic-hdl: AJ4-RIPE > * notify: quardian(a)aball.de > * mnt-by: ABALL-NCC-MNT > * changed: knocke(a)nic.de 19941214 > * changed: knocke(a)nic.de 19950103 > * changed: jennen(a)aball.de 19990623 > * changed: jennen(a)aball.de 20000621 > * source: RIPE > * > * whois -h whois.denic.de AJ4-RIPE > * the denic says: > * > * % Copyright (c)2000 by DENIC > * % > * % Restricted rights. > * % > * % > * % Except for agreed Internet operational purposes, no part of this > * % information may be reproduced, stored in a retrieval system, or > * % transmitted, in any form or by any means, electronic, mechanical, > * % recording, or otherwise, without prior permission of the DENIC > * % on behalf of itself and/or the copyright holders. Any use of this > * % material to target advertising or similar activities are explicitly > * % forbidden and will be prosecuted. The DENIC requests to be notified > * % of any such activities or suspicions thereof. > * > * person: Andreas Jennen > * address: aball Internet Netzdienste GmbH > * address: Roscherstr. 10 > * address: 30161 Hannover > * address: DE > * e-mail: jennen(a)aball.de > * nic-hdl: AJ4-RIPE > * changed: lastchange(a)denic.de 20000621 > * source: DENIC > * > * that is not the same, we do not see> notify. mtn-by, history > * > * That is nonsence ! > * > * > * Are you not able to let work an domain whois server for Europe ? **** I am perfectly convinced that the RIPE NCC would be capable of engineering and operating such a service. Although, for the moment at least, the prerequisites (like community consensus, financial support, and obvious solutions to the massive **** scaling issues) are not in place. > * No, then i will say on the next meeting, that the RIPE organisation > * should change to an new and better and cheaper organisation ! **** Well, you might be able to provide RIPE (the community) with guidance on how to become a new and better organisation, but I doubt that it is going to be cheaper - because participation in RIPE (the community) **** is for free :-) **** Assuming that you intend to provide input to the RIPE NCCs activity plan and funding model, then you should use the established channels (talking to the RIPE NCC's management, membership mailing list, NCC **** General Assembly,...) > * If you don not want to answer this request, please give it to your > * General Manager ! > * > * > * Gruss Andreas Jennen. > * -- / \__ Festverbindungen auch 34 MBit/s und 155 MBit/s erhaeltlich > * ( *\___ <- Nando,Andreas Jennen, Roscherstr. 12, 30161 Hannover, DE > * / O EMAIL jennen(a)aball.de Voice: (+49 511)270 737-0, Fax:699091 > * / (_____/ Pos(Grad, Minuten): N 52 18.559';E 009 35.714' Hoehe: 112 m > * /_____/ U http://www.aball.de Privat: http://www.jennen.de > * > * > * ----- Forwarded message from whois-info(a)nic.at ----- > * > * From whois-info(a)nic.at Fri Jan 5 20:51:41 2001 > * From: whois-info(a)nic.at > * Message-ID: <645525DACC86A945B4DA2B199D8481F64412BA(a)nics-01.sbg.nic.at> > * To: jennen(a)aball.de > * Subject: WHOIS-Database .at-Domains > * Date: Fri, 5 Jan 2001 20:48:24 +0100 > * X-Mailer: Internet Mail Service (5.5.2650.21) > * X-MIME-Autoconverted: from quoted-printable to 8bit by sonne.aball.de id UAA > * 20098 > * > * Sehr geehrte Damen und Herren! > * > * Sie erhalten folgende Information von nic.at, da Sie als Kontaktperson > * (tech-c oder zone-c) einer .at-Domain eingetragen sind. > * > * This is an information from nic.at to all contacts (tech-c and zone-c) of > * .at-domains. To view the english version please click here: > * www.nic.at/english/whois_info.html. Please note your nicat-handle below. > * > * Aus administrativen Gruenden kann die Organisation Ripe (www.ripe.net) ihre > * Datenbank nicht mehr zur Speicherung von Domain-Daten ("Whois"-Abfragen) zur > * Verf|gung stellen. > * nic.at wird daher die relevanten Daten aus der Ripe-Datenbank absiedeln und > * lokal verwalten. Die Funktionalitaet und Wartung von Domains ist damit in > * keinster Weise beeintraechtigt. Die Domain-Daten sind weiterhin (auch |ber > * www.ripe.net) oeffentlich abrufbar und sicher verwaltet - es wird lediglich > * bei Abfragen direkt auf die nic.at-Datenbank zugegriffen. > * > * Im Zusammenhang mit dieser Umstellung werden alle bestehenden Ripe-Handles > * bei .at-Domains automatisch durch NICAT-Handles ersetzt. Nach einer > * Uebergangsphase wird nic.at bei Neuregistrierungen und Aenderungen nur noch > * NICAT-Handles akzeptieren. Beruecksichtigen Sie das bitte, falls Sie > * Ripe-Handles in Ihrer internen Software zur Verwaltung von .at-Domains > * verwenden. > * Sollten Sie Ihr Ripe-Handle f|r andere Ripe-Services benutzen, bleibt er > * nat|rlich bestehen und ist bei Ripe weiterhin g|ltig. > * > * ********************************************************** > * Ihr 'alter' Ripe-Handle/your old ripe-handle: AJ4-RIPE > * Ihr neuer NICAT-Handle/your new nicat-handle: AJ552432-NICAT > * ********************************************************** > * > * Folgender Zeitplan ist f|r die Umstellung vorgesehen: > * ab 12.1.2001 kvnnen NICAT-Handles verwendet werden - es sind Ripe-Handles > * UND NICAT-Handles gueltig. Alle domain objects, die davor angelegt oder > * geaendert wurden, werden im alten Format ausgegeben. Alle neuen domain > * objects, erzeugt durch Neuantrag oder Aenderung werden im neuen Format > * ausgegeben. Eine Aenderung bewirkt, dass das Object in der Ripe Datenbank > * geloescht wird und das in Object in der nic.at-Datenbank zum Tragen kommt. > * ab 29.1. gelten bei nic.at nur mehr NICAT-Handles, die .at-Domain Objects > * werden in der Ripe-Datenbank geloescht. Bitte verwenden Sie ab 29.1. keine > * RIPE-Handles mehr! Bis zum Ende der Loeschaktion kann es zwei Ausgabeformate > * (alt oder neu) geben. > * > * Eine detaillierte Beschreibung der Aenderungen in den Domain und Person > * Objects finden Sie auf unserer Homepage unter > * (www.nic.at/german/whois_info.html), FAQ's zum Thema Whois unter > * www.nic.at/german/whois_FAQ.html. > * > * Bei weiteren Fragen kontaktieren Sie bitte das nic.at Team unter 0800 800 > * 888 844 bzw. per E-Mail unter whois-info(a)nic.at > * Wir helfen Ihnen gerne weiter. > * > * Ihr nic.at Team > * > * nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H. > * Jakob-Haringer-Stra_e 8 > * A-5020 Salzburg > * > * Infos zu Domainregistrierung www.nic.at > * > * E-Mail: whois-info(a)nic.at > * Tel.: +43 (662) 4669-844 > * Fax: +43 (662) 4669-29 > * In Oesterreich gebuehrenfrei: > * Tel.: 0800 800 888-844 > * Fax: 0800 800 888-29 > * > * ----- End of forwarded message from whois-info(a)nic.at ----- > * > * ----- End of forwarded message from Andreas Jennen ----- > >----- End of forwarded message from RIPE NCC Hostmaster -----

1 0