- db-wg - mailman.ripe.net

Release of prototypes of RPSLng IRRToolSet and Whois Server
by DB-News 30 Jul '03

30 Jul '03

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

1 0

X.509 authentication in the RIPE Database
by Tiago Antao 22 Jul '03

22 Jul '03

Dear Colleagues, [Apologies for duplicate e-mails] As previously discussed in RIPE 44 and 45, please find below the proposal to add X.509 authentication to the RIPE Database. ******************************************************************** X.509 Certificate Authentication in the RIPE Database 0. Objective To make a new method of authentication available using X.509 certificates. 1. Motivation The RIPE Database currently has 5 methods of authentication, none of these are completely satisfactory with regard to security, standards support (de facto and de jure), pervasiveness and integration. The X.509 authentication mechanism would satisfy all of these factors: 1. Security: X.509 allows for the use of digital signatures, making it unnecessary to send clear passwords via e-mail. The current PGP authentication also provides this feature. 2. Standards support: X.509 is an ISO standard and is the only mechanism supported by mailers and clients used in more than 90% of communications with the RIPE NCC. 3. Pervasiveness: X.509 can be utilised with several communication mechanisms, not only mail. A common example is SSL/HTTPS. No other authentication mechanism is as strong and easily available with the web. 4. Integration: This authentication method will integrate seamlessly with the general framework of security in use at the RIPE NCC. It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method. 2. User visible changes a. Requirements To be able to the X.509 authentication method the user requires a certificate issued through the RIPE NCC LIR portal. Information on how to obtain a certificate can be found at: http://lirportal.ripe.net/lirportal/faq/pki.html Therefore the X.509 method would only be available to LIRs. This can be changed if the community so desires. b. Maintainers The auth: attribute of the mntner object will have a new authentication scheme, X509. The parameter will be a Distinguished Name (DN) according to RFC 2253. There is an important fundamental difference between PGP authentication and X.509; the database does not need a key-cert object for X.509 certificates, the DN has to be trusted. This means the certificate must be signed by a trusted authority and that self-signed certificates will not be accepted. The trusted authority will be the RIPE NCC Certificate Authority that is currently only available to LIRs. Following is an example of a maintainer with X.509 authentication: mntner: RIPE-DBM-MNT descr: Mntner for RIPE DBM objects. admin-c: AMR68-RIPE tech-c: RD132-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=eu.ripe.dbm notify: ripe-dbm(a)ripe.net mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030617 source: RIPE For users the only variable part within the new auth: attribute is the CN (Common Name). c. Submitting updates via e-mail Updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. This key must also be made available to the mailer. Users that have a mail user agent that does not support S/MIME might consider using OpenSSL S/MIME facilities to prepare their mails. d. Submitting updates via webupdates Webupdates will accept client-side certificates. This means that the strongest type of authentication possible will be easily available for users using the web. For this to be possible the certificate and private key have to be loaded in the user browser.

4 4

New Draft Documents for review: IPv4 Policy & Status Attribute in Inetnum objects
by leo vegoda 21 Jul '03

21 Jul '03

Dear Colleagues, The RIPE NCC is pleased to announce the publication of a draft of the updated RIPE IPv4 policy document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (currently ripe-234). We have also published a draft document detailing proposed changes to the “status:" attribute in inetnum objects. Both documents can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the draft IPv4 policy document include the following: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). - The document now specifies database registration requirements. If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). The draft document on “status:" attributes proposes changes to the values of “status:" attributes. There is a new “status:" attribute value to support the sub-allocation policy, approved by the RIPE LIR Working Group. New wording is suggested, too. This should make the meaning of “status:" attributes more clear to the majority of Whois users. Feedback on both documents should be sent to the <address-policy-wg(a)ripe.net> mailing list for a period of five weeks. This review period will end on 28 August 2003. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Re: [db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Jul '03

16 Jul '03

Randy, >let the RIRs spend a few of the bucks they have getting their certs >signed by a well-trusted root CA. is there any? Or to be more precise, why (as an RIR customer) should I trust a commercial CA more than a RIR? >randy I think what is happening here is a misunderstanding and/or an attempt to mix and match advantages, capabilities and technology of a hierarchical 3rd party trust system vs. a (PGP-like) web of trust approach. Wilfried.

1 0

Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Tim Christensen 11 Jul '03

11 Jul '03

> when you say that the trend among the other RIRs is to go for X.509 > certificates, could you please elaborate on what they are > doing and how > far they are? Greetings all, Currently, ARIN is working toward deployment of X.509 as a strong authentication method for securing email template submissions. We expect implementation to occur later this year. After X.509 deployment for templates, ARIN will explore both the expansion of X.509 into other methods of interfacing with ARIN, as well as other strong authentication mechanisms. Regards, Tim Christensen Database Administrator American Registry for Internet Numbers (ARIN) (703) 227 9876

1 0

X-NCC-RegID : cm.intelcam deleting objects
by Local Internet Register 30 Jun '03

30 Jun '03

Date: Wed, 25 Jun 2003 14:09:01 -0100 (GMT) From: Local Internet Register <registry(a)intelcam.cm> Subject: X-NCC-RegID : cm.intelcam deleting objects To: lir-help(a)ripe.net Cc: registry(a)intelcam.cm MIME-Version: 1.0 Content-MD5: ZpkYzRVbqYcHSqym9KzPtA== Hello! This is LIR Cameroon. We would like to know how to delete the following objects from the RIPE database. Best regards TONYE Antoine Joseph Junior inetnum: 195.24.204.128 - 195.24.205.63 netname: NEWTECH descr: Internet Service Provider descr: BP 6269 Yaounde Cameroon country: CM admin-c: EAA11-RIPE tech-c: DM5338-RIPE rev-srv: ns.ripe.net rev-srv: fw.itu.ch rev-srv: sanaga.camnet.cm rev-srv: lom.camnet.cm status: Assigned PA notify: registry(a)intelcam.cm mnt-by: RIPE-NCC-NONE-MNT change: registry(a)intelcam.cm 20000412 source: RIPE person: David MABVOURI address: BP 6269 Yaounde Cameroon phone: +237 22 19 82 fax-no: +237 22 19 81 e-mail: david.mabvouri(a)wipo.int nic-hdl: DM5338-RIPE notify: registry(a)intelcam.cm changed: registry(a)intelcam.cm 20000411 source: RIPE

2 1

New "status" tag of REVOKED requested
by Hank Nussbacher 24 Jun '03

24 Jun '03

The following was posted to APNIC without much comment. Since RIPErs are more outspoken, I'd like to raise it here as a possible idea for implementation. >I am part of a volunteer team along with Barry Greene and Terry Baranski >that contact Internet users (ISPs and corporates) when they start >announcing something wrong on the Internet. Recently, Geoff Huston updated >his CIDR report - http://bgp.potaroo.net/cidr/#Bogons and up popped a >number of APNIC customers that were announcing prefixes that were not >allocated in APNIC. > >Turns out that the customers membership was "closed" and APNIC tried >contacting them with no success. APNIC waits about 90-120 days before >closing a member for non-payment. APNIC then sends an email informing the >upstream to stop announcing the IP range that has been reclaimed from the >closed member. Then they remove all the database objects which are related >to this organisation from the WHOIS database. After a one year period, >APNIC will start to reallocate/reassign that particular IP range to other >organisations. > >The problem is that the upstream or even the customer themselves continue >to use the prefix and announce it to the Internet, thereby falling into the >Bogon category. > >I think 90-120 days is too little before removing the inetnum object. I >also think that a better a tactic would be to add a "remarks" to the >inetnum or perhaps create a new "status" tag such as REVOKED. I also think >such a policy should be uniform between RIRs. > >Comments? -Hank

2 1

Hi to the group
by A. Hakan ASKAR 05 Jun '03

05 Jun '03

Dear all ! We are an ISP operating in Turkey called Gediknet. We got some problems about managing our IP blocks. As Gediknet A.S. these ip blocks ( 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the whois db you can see that these ip's are mnt-by your RIPE. We are trying to get an AS Number but as you can imagine we are not the mnt !. To correct this problem, what can we do ? Regards ; A. Hakan ASKAR Gediknet A.S. Manager

1 0

Re: Improvements to database update software
by DB-News 04 Jun '03

04 Jun '03

Dear Colleagues, [apologies for duplicate messages] This is to announce that the transition period for the introduction of new database update software is over. This means that the mail boxes auto-dbm-old(a)ripe.net and auto-dbm-new(a)ripe.net are not available any more and all update messages to auto-dbm(a)ripe.net will be processed by the new database update software. Best regards, -- Engin Gunduz RIPE NCC Database Group -- DB News wrote 23 Apr 2003: > > [apologies for duplicate messages] > > Dear Colleagues, > > The Database Group at the RIPE NCC has been working on restructuring > the dbupdate program. This is the part of the RIPE Whois server that > processes update requests from users. > > The main goal has been to improve the acknowledgement messages that > users receive from the RIPE Whois Database and provide clearer error > reporting and authorisation information. We have also been able to > make the software easier to maintain and modify. This will reduce the > time spent fixing bugs and adding new features. > > Details may be found here: > > http://www.ripe.net/db/dbupdate/ > > A page further explaining the new acknowledgements can be found here: > > http://www.ripe.net/db/dbupdate/acknowledgments.html > > The new dbupdate messages have a different format. Therefore a phased > approach to introducing the new server has been taken. For a period we > will use the new dbupdate in parallel with the old one. This will > allow people using automated tools time to update their software. > > PRE-MIGRATION > Before the new dbupdate was available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > DAY-X, Wednesday, 23 April, 2003 > The new dbupdate is available but must be requested specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Y, Wednesday, 7 May, 2003 > The new dbupdate is the default but the old dbupdate may be requested > specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 > The old dbupdate is no longer available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > > Best regards, > > -- > Shane Kerr > Database Group > RIPE NCC

1 0

changed-lines in objects.
by Fredrik Widell 26 May '03

26 May '03

Hi db-wg, I have a suggestion which maybe is good or bad :) A thought occured to me (as I for the xxxx'th time was accused of hacking somebody who has a firewall). The changed-line in every object simply refers to a mail-adress and a timestamp. Whould'nt it be more accurate to have a nic-hdl instead of just a mailadress there? managers of objects move, and mailadresses gets obsolete, and the only thing they are used for is to send abuse-matters, which of course are the wrong recipient in 99.9% of the cases, but if there was a nic-hdl, one could give information via that nic-hdl on how to get in contact with 'good' recipients, or the users would have to actually think and maybe realize that the other names that occur in an answer from ripe-db possibly could be the right recipients for abuse-matters. an example, instead of this: inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: ber(a)sunet.se 19940420 changed: fredrik(a)sunet.se 19990211 changed: fredrik(a)sunet.se 19991105 source: RIPE there would be inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: BE10 19940420 changed: FW526-RIPE 19990211 changed: FW526-RIPE 19991105 source: RIPE Comments are welcome. -- Best regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------

4 4

Problems with route object update
by Marcus.Ruchti＠colt.de 22 May '03

22 May '03

Hi all, I've recognized that we have massive problems in the last weeks with RIPE database updates by other ISP's. e.g. a new customer wants that we will announce a PI network used by him but it is maintained by another LIR. I've asked for creating a route object with our maintainer several times without success. I think all this happens with intention to constrain the business activity of the competitor ! Is there a possibility to insert the RIPE-NONE Maintainer in the whole PI blocks (e.g. /16). In this step I won't mention the names of those ISP's... regards, Marcus Ruchti COLT Telecom GmbH

1 0

Re: [db-wg] Slash notation
by Janos Zsako 22 May '03

22 May '03

> From db-wg-admin(a)ripe.net Thu May 22 14:59:10 2003 Dear all, > > ... Just another suggestion (from what I experienced in my environment): > > > >Would it be possible to treat/convert > > > >inetnum: 193.0.0.221 > > > >to > > > >inetnum: 193.0.0.221 - 193.0.0.221 > > > >(the 'single host') > >? > > is there a possibilty for ambiguity? I guess there is, especially if the last element is 0 (e.g. 194.152.133.0, which probably can be confused with 194.152.133.0/24). It cannot be ambiguous, however, if the last element of the dotted quad is an odd number. > Probably not if we have all 4 fields of the dotted quad included. > > Maybe we c/should require 193.0.0.221/32 here to be on the safe side? I would prefer this latter (i.e. requiring the /32). Janos

2 1

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Ulrich, Shane, > ... Just another suggestion (from what I experienced in my environment): > >Would it be possible to treat/convert > >inetnum: 193.0.0.221 > >to > >inetnum: 193.0.0.221 - 193.0.0.221 > >(the 'single host') >? is there a possibilty for ambiguity? Probably not if we have all 4 fields of the dotted quad included. Maybe we c/should require 193.0.0.221/32 here to be on the safe side? Wilfried.

1 0

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Shane! >Short answer: > >When version 3 of the Database software was designed, one of the >principles used was to not change user data as it was submitted. >This included the transformation you defined. Still a reasonable guideline, I'd say.... >The easiest solution would be to convert the CIDR to ranges, as you >suggest, so: > >inetnum: 193.0.0.0/20 > >Would become: > >***Warning: inetnum '193.0.0.0/20' converted to '193.0.0.0 - 193.0.7.255' > >inetnum: 193.0.0.0 - 193.0.7.255 > . > . > . > >If this makes sense, we'll include this change shortly. Yes, please! [ and still: yes, please - even after reading your in-depth explanation... ] Regards, Wilfried.

1 0

RE: [db-wg] Slash notation
by ipmaster＠bt.com 22 May '03

22 May '03

Shane, sounds good to me !! Thanx Dave Trickett BTnet -----Original Message----- From: Shane Kerr [mailto:shane@ripe.net] Sent: 21 May 2003 16:56 To: IPMASTER G Cc: db-wg(a)ripe.net Subject: Re: [db-wg] Slash notation On 2003-05-21 16:26:43 +0100, ipmaster(a)bt.com wrote: > Hi > > Quick question:-) > We used to be able to update (via email) the Database with new > inetnums using slash notation. Since the introduction of RPSL, this > facility has been lost, would it be possible to re-introduce it? > I can see the benefits of using the long hand version if I am > updating with a /27 and a /28, such as (*.*.*.64 - *.*.*.111). > But for Inetnums that fall on the bit boundary would not make sense > to enable the slash? > If I update a route object I can still use the slash notation. Short answer: When version 3 of the Database software was designed, one of the principles used was to not change user data as it was submitted. This included the transformation you defined. The easiest solution would be to convert the CIDR to ranges, as you suggest, so: inetnum: 193.0.0.0/20 Would become: ***Warning: inetnum '193.0.0.0/20' converted to '193.0.0.0 - 193.0.7.255' inetnum: 193.0.0.0 - 193.0.7.255 . . . If this makes sense, we'll include this change shortly. Explaination (for the curious): The reason that these types of modifications were avoided in the original design is because RPSL allows a number of formats that can make the changes difficult. For example: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0 + - # heck, you can even put a comment here 193.0.7.255 + # and at the end too Modifying this kind of attribute can be problematic, because the value is split across many lines, and has comments in the middle. However, with your suggestion it would be possible to do something like converting: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0/21 + # but still parsable! Into the following: inetnum: # this +# is a valid # inetnum attribute 193.0.0.0 - 193.0.7.255 + # but still parsable! Since the CIDR-notation is "atomic", we don't have to worry about values split across lines or with comments inside. Note that comments and split lines in the primary attributes are very, very rare, but it is technically possible for any user that wishes to do so. -- Shane Kerr RIPE NCC

2 1

Slash notation
by ipmaster＠bt.com 21 May '03

21 May '03

Hi Quick question:-) We used to be able to update (via email) the Database with new inetnums using slash notation. Since the introduction of RPSL, this facility has been lost, would it be possible to re-introduce it? I can see the benefits of using the long hand version if I am updating with a /27 and a /28, such as (*.*.*.64 - *.*.*.111). But for Inetnums that fall on the bit boundary would not make sense to enable the slash? If I update a route object I can still use the slash notation. Dave Trickett BTnet

3 2

action item AP-42.3 - problems of multiple hashed passwords
by Larry J. Blunk 14 May '03

14 May '03

This is an update on AP-42.3 regarding identifying users of multiple hashed passwords (CRYPT-PW or MD5-CRYPT) in a mntner. Merit has implemented an option in it's web-based update form to include an "id" in the comment field of an "auth:" attribute. Additionally, the date and time of creation of the hashed password is included (should one want to keep track of the age of a particular password). Below is an example -- auth: CRYPT-PW Fa1QDrka0aOOM #Id:billg Created:20030514 09:42:45(UTC) As a further note, we have implemented (but not deployed) support for hashed password hiding. When this is deployed, the hash value of a CRYPT-PW will be replaced with the string "HIDDENCRYPTPW" when a mntner object is queried or mirrored. I'm not sure how much of this is of interest to the RIPE community (particularly with the PKI support on the horizon), but I thought I would throw it out for consideration. Regards, Larry Blunk Merit Network

1 0

Webcast RIPE 45 Announcement
by RIPE NCC Meeting Registration 13 May '03

13 May '03

Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to <ripecast(a)ripe.net>. Regards, RIPE Meeting Coordination Team

1 0

Prototype of RPSLng Whois server
by DB-News 12 May '03

12 May '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC Database Group announces an RPSLng prototype Whois server on host rpslng.ripe.net, port 53001. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. The prototype RPSLng Whois server implements the draft draft-damas-rpslng-00.txt (ftp://ftp.ripe.net/internet-drafts/draft-damas-rpslng-00.txt). In the near future we will be implementing the new RPSLng draft (http://www.radb.net/rpslng.html). The prototype database contains a snapshot of the RIPE Whois Database. It can be updated by sending mails to <rpslng-auto(a)ripe.net>. Please note that this database is for test purposes only. Updates performed on it will _not_ be reflected in the RIPE Whois Database. More details can be found at: http://www.ripe.net/db/rpslng Please contact ripe-dbm(a)ripe.net for any comments. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

message
by CMC 10 May '03

10 May '03

Hello Friends; I have a specific interest in receiving ripe as I am a registered channel manager on the Undernet & in my role must contact Undernet Administrators on people who abuse this chat network on IRC. I am 33 years old; attend grad school and work my way through Grad school. I have been a registered channel manager since 1997 and as such the Undernet has the same address as above for me. It's a requirement. I can offer hostmasks of people who are IRC abusers and help in anyway I am asked if I can do it . Thank you, Sincerely, charles michael capozzi

1 0

SYNC-Update failed
by Nacamar AS Guardian 09 May '03

09 May '03

hi all, i use the sync for create. delete and update my objects in the ripe-db. Today the dbupdate - routine failed, using pgp. via mail the new version is ok. has i left any statemenat from the ripe ? greetings, sven eisenmann ------------------------------------------------------------------- Sven Eisenmann NCC Senior Manager Network Administration Tiscali Business GmbH Robert-Bosch-Strasse 32 D-63303 Dreieich Telefon: +49(0)6103-916 0 Telefax: +49(0)6103-916 1881 E-Mail: guardian(a)nacamar.net www.tiscali.de www.tiscali-business.de -------------------------------------------------------------------

2 1

(typo corr.) draft agenda (v2), for DB-WG meeting, RIPE 45, Barcelona, ES
by Wilfried Woeber, UniVie/ACOnet 02 May '03

02 May '03

[ correction of a small typo, thanks to Mally for spotting it! ] ______________________________________________________________________ Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 2nd - preliminary - draft: Proposed Agenda for the DB-WG Meeting at RIPE 45 in Barcelona, ES. As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Catalunya, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 2. Draft A. Administrative stuff (WW, chair) 10 min . scribe: Nigel T. B. Action Items 15 min C. DB operational update (RIPE NCC, Shane K.) 20 min . including status of ERX D. Quality of contact data (RIPE NCC, Shane K.) 10 min . discussion / next steps / which WG? +10 min F. New "dbupdate" (RIPE NCC, Denis W.) 15 min G. Discussion: to disallow auth: NONE ( [ Hank N. ] ) 15 min H. (tbc) DB-SW teams up with... (UniVie-ACOnet, Ulrich K.) 20 min . the UniVie Netw.Info.Sys.: I. follow-Up on last meetings issues (Chair, WW144) 30 min . Organisation object proposal (RIPE NCC, Shane K.) . status: SUB-ALLOCATED PA (Space.Net, Gert D.) . reclaim: - Attribut (Space.Net, Gert D.) . allowing "generated" attributes in updates (WW et.al.) . Key Certificates to person: role: ? Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 2-MAY-2003 12:26:17 UTC _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

draft agenda (v1), for DB-WG meeting, RIPE 45, Barcelona, ES
by Wilfried Woeber, UniVie/ACOnet 02 May '03

02 May '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st - preliminary - draft: Proposed Agenda for the DB-WG Meeting at RIPE 45 in Barcelona, ES. As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Catalunya, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft A. Administrative stuff (WW, chair) 10 min . scribe: Nigel T. B. Action Items 15 min C. DB operational update (RIPE NCC, Shane K.) 20 min . including status of ERX D. Quality of contact data (RIPE NCC, Shane K.) 10 min . discussion / next steps / whihc WG? +10 min F. New "dbupdate" (RIPE NCC, Denis W.) 15 min G. Discussion: to disallow auth: NONE ( [ Hank N. ] ) 15 min H. (tbc) DB-SW teams up with... (UniVie-ACOnet, Ulrich K.) 20 min . the UniVie Netw.Info.Sys.: I. follow-Up on last meetings issues (Chair, WW144) 30 min . Organisation object proposal (RIPE NCC, Shane K.) . status: SUB-ALLOCATED PA (Space.Net, Gert D.) . reclaim: - Attribut (Space.Net, Gert D.) . allowing "generated" attributes in updates (WW et.al.) . Key Certificates to person: role: ? Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 2-MAY-2003 11:44:15 UTC _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

Announcement RIPE NCC RR Training Course
by RIPE NCC Training 01 May '03

01 May '03

------- Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT describe how to receive Internet resources from the RIPE NCC not describe to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ******************************************************************************** COURSE DATES AND VENUES ======================= Date: Friday 11 July 2003 Time: 0900 - 1700 Location: Vienna, Austria AND: Date: Friday 29 August 2003 Time: 0900 - 1700 Location: Helsinki, Finland AND Date: Monday 8 September 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands *********************************************************************************** REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

New Draft Document announcement
by RIPE NCC WebMaster 29 Apr '03

29 Apr '03

Dear Colleagues, The RIPE NCC has prepared a draft document titled "Improved Secure Communication System for RIPE NCC Members": http://www.ripe.net/ripe/draft-documents/pki-20030429.html Abstract There is a need for secure communication between the RIPE NCC and its members. This document presents an overview of the current communication system, and a new approach based on X.509 PKI (Public Key Infrastructure) technology and standards that will make interaction with the services provided by the RIPE NCC to its members more convenient and secure. Finally, the phases necessary to implement the system are described. The idea behind publishing this as a draft document is to give RIPE NCC members time to read it and provide feedback. If the LIRs agree with the ideas presented, then it will become a RIPE document and act as a basis for the project. The draft document can be discussed on the LIR Working Group, <lir-wg(a)ripe.net>, or you can send comments to <pki-suggestions(a)ripe.net>. Best regards, -- Shane Kerr RIPE NCC

1 0