- db-wg - mailman.ripe.net

RE: Proposal for adding external repository reference to import/e xpor t attributes
by Lu, Ping 25 Aug '02

25 Aug '02

Right now, I think we only need to implement the "::" notation in the RFC2725. For this I think RFC2725 is the result of the standard process and there is no need to re-open RPSL WG to repeat that again. However the reason we proposed to implement "::" notation is to address the need for EXTERNAL REFERENCE. For that I think it might be necessary to start the WG discussion on how do we support the EXTERNAL REFERENCE in the near future. Let's just start implementing the "::" notation while we can also start the discussion on the topics of EXTERNAL REFERENCE. I don't know if here is the proper place to start the discussion or we should go somewhere else ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Mark Prior [mailto:mrp@mrp.net] > Sent: Saturday, August 24, 2002 8:08 AM > To: curtis(a)fictitious.org > Cc: Lu, Ping; db-wg(a)ripe.net; irrtoolset(a)ripe.net > Subject: Re: Proposal for adding external repository reference to > import/expor t attributes > > > At 3:10 PM -0400 23/8/02, Curtis Villamizar wrote: > >It is possible to reactivate a WG on the mailing list only, for the > >purpose of updating an existing RFC and not having a meeting. This > >was done with TCPLW for RFC1323. Cengiz would need to > update RPSL (as > >primary author and keeper of the source of that document). > > > >Is the only change needed at this point the :: notation to indicate > >external repository? If so, no change is needed to RFC-2622 > since the > >:: notation is called for in RFC-2725 and it wouldn't be worth > >updating RFC-2622 just for that. > > > >What you really need to do is get Larry Blunk to update the > ISI tools. > > Curtis, > > I wasn't the person suggesting making changes, I was just suggesting > that you needed to follow a procedure in order to make it happen and > couldn't just "fix" it in software. I would suggest if people think > this is a good idea (and I haven't really thought about it) then > perhaps merging it into the RPSLng work would be the way to go. > > Mark. > >

1 0

Re: Proposal for adding external repository reference to import/expor t attributes
by Mark Prior 24 Aug '02

24 Aug '02

At 3:10 PM -0400 23/8/02, Curtis Villamizar wrote: >It is possible to reactivate a WG on the mailing list only, for the >purpose of updating an existing RFC and not having a meeting. This >was done with TCPLW for RFC1323. Cengiz would need to update RPSL (as >primary author and keeper of the source of that document). > >Is the only change needed at this point the :: notation to indicate >external repository? If so, no change is needed to RFC-2622 since the >:: notation is called for in RFC-2725 and it wouldn't be worth >updating RFC-2622 just for that. > >What you really need to do is get Larry Blunk to update the ISI tools. Curtis, I wasn't the person suggesting making changes, I was just suggesting that you needed to follow a procedure in order to make it happen and couldn't just "fix" it in software. I would suggest if people think this is a good idea (and I haven't really thought about it) then perhaps merging it into the RPSLng work would be the way to go. Mark.

1 0

Early Registration Transfer Project
by Joao Luis Silva Damas 21 Aug '02

21 Aug '02

Dear Colleagues, Prior to the formation of the RIPE NCC, all Internet resources were issued by the InterNIC and its predecessors, based in the USA. The RIPE community has decided to transfer registrations of resources used in the RIPE NCC Service Region to the RIPE Whois Database. Initially we will transfer Autonomous System Number registrations. The work will start on 21 August 2002, with the transfer of ASN records. Contacts for all registrations to be transferred will be notified by a separate e-mail detailing the process. A brief report on the results of the transfer process will be made at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there will be the opportunity to discuss any issues that may arise from the transfer of IPv4 registrations. A complete list of ASN registrations being transferred and details of the transfer process are available from our web site at: <http://www.ripe.net/ripencc/pub-services/db/erx.html> In the meantime should you have any further questions please contact us at: <er-transfer(a)ripe.net> Kind regards, Joao Damas RIPE NCC

2 2

call for input: draft agenda DB-WG RIPE#43, Rhodes, GR
by Wilfried Woeber, UniVie/ACOnet 21 Aug '02

21 Aug '02

Dear RIPE DB-WG community! I am pretty close to distributing the 1st draft for the Proposed Agenda, DB-WG meeting, during RIPE#43. It will again feature some of the "traditional" DB-WG items, as well as some items which have already been proposed by the RIPE NCC. If there are any other issues (_within the remit of the WG_) which you want to see on the draft agenda, or if you want to get a report/presentation slot, please come back to me (directly), asap. Thanks, regards, Wilfried (DB-WG chair) _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Transferring InterNIC space from ARIN Database to other RIR databases
by Gabriella Paolini 18 Aug '02

18 Aug '02

"Transferring InterNIC space from ARIN Database to other RIR databases". Any news about that? Regards, Gabriella Paolini ------------------------------------------------- GARR - The Italian Academic and Research Network http://www.garr.it m@il: gabriella.paolini(a)garr.it -------------------------------------------------

3 2

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

Phase 4 of the MAIL-FROM deprecation
by Andrei Robachevsky 16 Aug '02

16 Aug '02

Dear Colleagues, As you may know the third phase of phasing out the MAIL-FROM authentication scheme from the RIPE Database resulted in a very high rate of requests to update mntner objects coming to the Database Administration, ripe-dbm (please see my message on this subject http://www.ripe.net/ripe/mail-archives/db-wg/20020701-20021001/msg00021.html). The requests are coming from the owners of the mntner objects that still use only MAIL-FROM authentication scheme and therefore are locked. We still have about 1500 such mntner object whose owners didn't use the opportunity to update their objects during previous phases and now have to apply to ripe-dbm to fix this situation. Taking into account that this puts extra load on ripe-dbm and takes resources from serving the usual types of requests I'd like to propose a change for the phase 4 of the process of phasing out the MAIL-FROM authentication scheme. According to the agreed procedure (http://www.ripe.net/db/MD5-HOWTO.html#b._Migration_timeline) during the phase 4 maintainers with "auth:" attributes using "MAIL-FROM" will have those attributes removed. This is a clean-up step. In addition we would like to do the following: 1. mntners with MAIL-FROM authentication _only_ will be updated in the following way: - a password will be auto generated and all MAIL-FROM "auth:" attributes will be replaced with one auth: MD5-PW $1$<generated_string>; - a mnt-by: attribute will be added referencing a protected mntner RIPE-MAIL-FROM-MNT. This will serve as a tag. 2. A clear text password can be requested by sending an e-mail to ripe-dbm(a)ripe.net with the following in the subject line: MAIL-FROM:<mntner_name> without any spaces. The reply with the passphrase will be sent to contacts listed in "upd-to:" and admin-c's "e-mail:" of the mntner. 3. After that the mntner should be updated to remove the mnt-by: RIPE-MAIL-FROM-MNT attribute and to possibly change the password. 4. After a certain period of time (2 months) the service will be discontinued and decision will be made about the mntners that still haven't been modified (still bear the RIPE-MAIL-FROM-MNT tag). We will extend the deadline of the phase 4 till 15 August to have time to come to an agreement. I kindly ask you to consider this proposal and comment before that day. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 1

New Document available: RIPE-252
by RIPE NCC Document Announcement Service 15 Aug '02

15 Aug '02

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-252 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 15 August 2002 Format: PS=283252 TXT=134071 Obsoletes: ripe-251 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the functionality of version 3.0 of the RIPE Database that uses the Routing Policy Specification Language (RPSL) to represent all Database objects. It also implements the Routing Policy System Security (RPSS) to provide authorisation mechanisms to enable a higher level of security for Internet Routing Registries (IRR). Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. The Database Reference Manual is available from the WWW at the following URL: http://www.ripe.net/docs/databaseref-manual.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-252.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-252.txt plain text version

1 0

Updating inet6num objects with a legacy status attribute
by leo vegoda 06 Aug '02

06 Aug '02

Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" <http://www.ripe.net/docs/new-value-status.html> The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

Some updates were not processed today
by Andrei Robachevsky 05 Aug '02

05 Aug '02

Dear Colleagues, Unfortunately several (136) update messages were not processed by the RIPE Database today, 5 August 2002. We are reluctant to re-process them as this may override the changes that might have been made afterwards. If you haven't received an acknowledgement to the update you sent to the RIPE Database today, please re-submit it again. We sincerely apologise for the inconvenience this caused. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1