- db-wg - mailman.ripe.net

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