- db-wg - mailman.ripe.net

RV: FAILED update.
by jesus.iglesias＠bt.es 14 Oct '02

14 Oct '02

> Hello, > Can anyone tell me why did this update fail? > The robot answered: > > Update FAILED: Syntax error in object > ***Error: Error with class attribute, class invalid > > Thanks for your help ! > Regards. > > _________________________________ > Jesús Iglesias Fuente > IP Platforms & Services (Planning) > BT Ignite Spain > jesus.iglesias(a)ignite.com > Phone: (+34) 91.270.62.14 > Fax: (+34) 91.270.63.10 > _____________________________________________ > > > -----Mensaje original----- > De: Iglesias Fuente, Jesus > Enviado el: viernes 11 de octubre de 2002 13:09 > Para: 'auto-rpsl(a)ripe.net' > Asunto: longack > > password: 7djsfy25ddn > > as-set: AS-BTTEL > descr: BT Telecomunicaciones customers > members: AS8903 > members: AS3324, AS21025 > members: AS12334, AS20784 > members: AS12356, AS12636 > members: AS8239, AS12430 > members: AS12845, AS21268 > members: AS9192, AS13066 > members: AS13143, AS15734 > members: AS12946, AS15369 > members: AS15912, AS15937 > members: AS15963, AS16373 > members: AS16203, AS13205 > members: AS20815, AS20944 > members: AS16371, AS21368 > members: AS21193, AS20718 > members: AS20760, AS20607 > members: AS24830, AS21181 > members: AS15919, AS25267 > remarks: BT Telecomunicaciones customers ASs > tech-c: BTT2-RIPE > admin-c: EL729-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > > > aut-num: AS8903 > as-name: BT > descr: BT Tel AS 1 > import: from AS701 action pref=100; accept ANY > import: from AS5400 action pref=100; accept ANY > import: from AS3561 action pref=100; accept ANY > import: from AS2856 action pref=100; accept ANY > import: from AS6895 action pref=100; accept AS6895 > import: from AS3262 action pref=100; accept AS3262 > import: from AS8761 action pref=100; accept AS8761 > import: from AS8782 action pref=100; accept AS8782 > import: from AS8220 action pref=100; accept AS8220 > import: from AS4589 action pref=100; accept AS4589 > import: from AS12457 action pref=100; accept AS12457 > import: from AS12357 action pref=100; accept AS12357 > import: from AS6897 action pref=100; accept AS6897 > import: from AS12479 action pref=100; accept AS12479 > import: from AS12852 action pref=100; accept AS12852 > import: from AS2686 action pref=100; accept AS2686 > import: from AS3352 action pref=100; accept AS3352 > import: from AS3324 action pref=100; accept AS3324 > import: from AS2134 action pref=100; accept AS2134 > import: from AS12359 action pref=100; accept AS12359 > import: from AS3352 action pref=100; accept AS3352 > import: from AS13041 action pref=100; accept AS13041 > import: from AS12386 action pref=100; accept AS12386 > import: from AS9019 action pref=100; accept AS9019 > import: from AS5978 action pref=100; accept AS5378 > import: from AS12482 action pref=100; accept AS12482 > import: from AS9106 action pref=100; accept AS9106 > import: from AS12715 action pref=100; accept AS12715 > import: from AS702 action pref=100; accept AS702 > import: from AS3247 action pref=100; accept AS-3247 > import: from AS766 action pref=100; accept AS-766 > import: from AS3257 action pref=100; accept AS-NACAMAR > import: from AS6669 action pref=100; accept AS-BTES > import: from AS3324 action pref=100; accept AS3324 > import: from AS12334 action pref=100; accept AS12334 > import: from AS12356 action pref=100; accept AS12356 > import: from AS8239 action pref=100; accept AS8239 > import: from AS12430 action pref=100; accept AS12430 > import: from AS12636 action pref=100; accept AS12636 > import: from AS12845 action pref=100; accept AS12845 > import: from AS12946 action pref=100; accept AS12946 > import: from AS9192 action pref=100; accept AS9192 > import: from AS13066 action pref=100; accept AS13066 > import: from AS13143 action pref=100; accept AS13143 > import: from AS15369 action pref=100; accept AS15369 > import: from AS15734 action pref=100; accept AS15734 > import: from AS15912 action pref=100; accept AS15912 > import: from AS15937 action pref=100; accept AS15937 > import: from AS15963 action pref=100; accept AS15963 > import: from AS16373 action pref=100; accept AS16373 > import: from AS16203 action pref=100; accept AS16203 > import: from AS13205 action pref=100; accept AS13205 > import: from AS21025 action pref=100; accept AS21025 > import: from AS20815 action pref=100; accept AS20815 > import: from AS20784 action pref=100; accept AS20784 > import: from AS20944 action pref=100; accept AS20944 > import: from AS16371 action pref=100; accept AS16371 > import: from AS21368 action pref=100; accept AS21368 > import: from AS21268 action pref=100; accept AS21268 > import: from AS21193 action pref=100; accept AS21193 > import: from AS20718 action pref=100; accept AS20718 > import: from AS20607 action pref=100; accept AS20607 > import: from AS20760 action pref=100; accept AS20760 > import: from AS24830 action pref=100; accept AS24830 > import: from AS21181 action pref=100; accept AS21181 > import: from AS15919 action pref=100; accept AS15919 > import: from AS25267 action pref=100; accept AS25267 > export: to AS701 announce AS-BTTEL > export: to AS5400 announce AS-BTTEL > export: to AS3561 announce AS-BTTEL > export: to AS2856 announce AS-BTTEL > export: to AS6669 announce AS-BTTEL AS-BTTELESPANIX AS-BTTELCATNIX > export: to AS2134 announce AS-BTTEL AS-BTES > export: to AS2686 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS3324 announce AS-BTTEL AS-BTES > export: to AS3352 announce AS-BTTEL AS-BTES > export: to AS6895 announce AS-BTTEL AS-BTES > export: to AS6897 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS8220 announce AS-BTTEL AS-BTES > export: to AS4589 announce AS-BTTEL AS-BTES > export: to AS12457 announce AS-BTTEL AS-BTES > export: to AS12357 announce AS-BTTEL AS-BTES > export: to AS12479 announce AS-BTTEL AS-BTES > export: to AS12359 announce AS-BTTEL AS-BTES > export: to AS8782 announce AS-BTTEL AS-BTES > export: to AS12852 announce AS-BTTEL AS-BTES > export: to AS13041 announce AS-BTTEL AS-BTES > export: to AS12386 announce AS-BTTEL AS-BTES > export: to AS9019 announce AS-BTTEL AS-BTES > export: to AS8761 announce AS-BTTEL AS-BTES > export: to AS12482 announce AS-BTTEL AS-BTES > export: to AS3262 announce AS-BTTEL AS-BTES > export: to AS9106 announce AS-BTTEL AS-BTES > export: to AS12715 announce AS-BTTEL AS-BTES > export: to AS5378 announce AS-BTTEL AS-BTES > export: to AS3257 announce AS-BTTEL AS-BTES > export: to AS702 announce AS-BTTEL AS-BTES > export: to AS3247 announce AS-BTTEL AS-BTES > export: to AS766 announce AS-BTTEL AS-BTES > export: to AS12334 announce ANY > export: to AS12356 announce ANY > export: to AS8239 announce ANY > export: to AS12430 announce ANY > export: to AS12636 announce ANY > export: to AS12845 announce ANY > export: to AS9192 announce ANY > export: to AS13066 announce ANY > export: to AS3324 announce ANY > export: to AS13143 announce ANY > export: to AS15734 announce ANY > export: to AS12946 announce ANY > export: to AS15369 announce ANY > export: to AS15912 announce ANY > export: to AS15937 announce ANY > export: to AS15963 announce ANY > export: to AS16373 announce ANY > export: to AS16203 announce ANY > export: to AS13205 announce ANY > export: to AS21025 announce ANY > export: to AS20815 announce ANY > export: to AS20784 announce ANY > export: to AS20944 announce ANY > export: to AS16371 announce ANY > export: to AS21368 announce ANY > export: to AS21268 announce ANY > export: to AS21193 announce ANY > export: to AS20718 announce ANY > export: to AS20607 announce ANY > export: to AS20760 announce ANY > export: to AS24830 announce ANY > export: to AS21181 announce ANY > export: to AS15919 announce ANY > export: to AS25267 announce ANY > admin-c: EL729-RIPE > tech-c: BTT2-RIPE > notify: opsingguar(a)bt.es > mnt-by: BTTEL-MNT > changed: jesus.iglesias(a)bt.es > source: RIPE > ********************************************** Noticia legal Este mensaje electrónico contiene información de BT Ignite España S.A.U. que es privada y confidencial, siendo para el uso exclusivo de la persona (s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido lo antes posible. Gracias.

1 0

AW: Hierarchical authorisation failed, request forwarded to maint aine r ???
by Marcus.Ruchti＠colt.de 14 Oct '02

14 Oct '02

yes, I 've made the same experiences! 2 route objects, 2 different AS, same precision (/22). In the the RIPE DB are some of these examples... Marcus Ruchti -----Ursprüngliche Nachricht----- Von: Gert Doering [mailto:gert@space.net] Gesendet am: Montag, 14. Oktober 2002 10:38 An: Shane Kerr Cc: Ruchti, Marcus; db-wg(a)ripe.net Betreff: Re: Hierarchical authorisation failed, request forwarded to maintaine r ??? Hi, On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote: > Most objects are uniquely identified by the first attribute, or > "route:" in this case. However, you must include the "origin:" > attribute for a route object. So this is: > > route: 143.58.120.0/22 > origin: AS3320 > > The object you are trying to create will be: > > route: 143.58.120.0/22 > origin: AS8220 Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS. So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Mailing List Software Migration
by RIPE NCC WebMaster 10 Oct '02

10 Oct '02

Dear Mailing List Subscriber, The RIPE NCC will change its mailing list software from "majordomo" to "mailman" on 17 October 2002. The new mailing list software will give users more options to manage their subscriptions to the RIPE and RIPE NCC mailing lists. Additionally, this change is being made to ensure stability and continuity of mailing list management and archiving. The new mailing list software will give users a number of options using a web interface: - Subscribing and Unsubscribing to mailing lists - Reviewing general information about the mailing lists - Viewing subscriptions to mailing lists - Temporarily disabling mail delivery - Choosing between regular and digests of mailing list postings - Acknowledgements to postings The web interface will be located at the following URL: http://www.ripe.net/mailman/ As well as using the web interface, mailing list users can manage their subscription and retrieve information by using an e-mail client. Further details on this are available at the above URL. Please note that if mailing list users are already subscribed to one or more mailing lists, they do not have to take any action. Messages can still be sent to the regular mailing lists addresses and subscriptions will not have to be re-confirmed. If you have any questions about this migration, please feel free to send an e-mail to <webmaster(a)ripe.net> Kind Regards, Jeroen Bet RIPE NCC Mailing List Moderation

1 0

RIPE Whois Server version 3.1.1
by RIPE Database Administration 09 Oct '02

09 Oct '02

Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of Version 3.1.1 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - MD5-PW authentication added. - IPv6 status changed to comply with new RIPE policy. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.1.1 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.1.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.1-nocxref.tar.gz A diff for the 3.1.1 "nocxref" version is also available, if you already have 3.1.0 and would prefer to patch that version instead, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.1.0-nocxref-3.1.1… The client has been updated, with a minor performance increase: ftp://ftp.ripe.net/tools/ripe-whois-3.1.1.tar.gz The Object Parsing Library (OPL) standalone source has also been updated, and is identical to the library used with the release. In the future, we will be releasing the OPL at the same time as the RIPE Whois server to keep them synchronised: ftp://ftp.ripe.net/ripe/dbase/software/RPSL-OL-3.1.1.tar.gz If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net> -- Shane Kerr RIPE NCC

3 6

creation of taskforce to support the ERX project (early registration xfer)
by Wilfried Woeber, UniVie/ACOnet 04 Oct '02

04 Oct '02

Dear participants in the DB and LIR WGs, as discussed and agreed in the DB-WG in Rhodes, and reported to the plenary, this is the "heads up" for the creation of a TaskForce (ERX-TF) to help in planning and test-driving the procedures and activities required to *most efficiently* perform the transfer of "early registrations" (sometimes also referred to as "legacy" IPv4 address space) from the ARIN DB to the RIPE DB.. [ For background information about the ERX Project please refer to the RIPE / RIPE NCC web pages. ] The proposed name of the TaskForce is "ERX-TF" . The preliminary and initial description of the activity is as follows: "The goal of the TF is to develop a proposal to the community of the transfer of early registration IPv4 address records (ERX) from ARIN to the RIPE NCC." For a start, I'd expect the TF to review the lessons learned from the transfer of AS Number Objects, and to investigate new or different issues with the already agreed transfer of IPv4 address space objects. The necessary next steps are 1) to ask the bigger community, by way of the mailing lists, whether there are any objections against the creation of the TF 2) to work on a refinement of the mandate, tasks to perform, and the expected results 3) to agree on a schedule, set of participants and to find a coordinator. Most of the work should be done by way of exchanging email amongst the TF Partcipants. Following up on expressions of interest as received during the RIPE43 WG session, an initial list of individuals would be put onto the mailing list. [ please see at the bottom of this mail ] Of course, if you are no longer interested - just let us know. Also, if you _are_ interested to join in - but did not or could not indicate your interest in Rhodes, please get back to us asap! Assuming that there would not be a major show-stopper, could I ask the NCC to follow up with any useful info (list name, draft schedule,...) to get us going as soon as possible? Cheers, Wilfried. Initial list of TF particpants: Havard Eidnes <he(a)uninett.no> Hank Nussbacher <hank(a)att.net.il> Gabriella Paolini <gabriella.paolini(a)garr.it> Kristian Rastas <kristian.rastas(a)sonera.com> Nigel Titley Ruediger Volk Wilfried Woeber <woeber(a)cc.univie.ac.at> _________________________________:_____________________________________ 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 2

Draft Minutes DB-WG RIPE 43
by Nigel Titley 01 Oct '02

01 Oct '02

I'm sure I posted this set of minutes, but I can't find it on the mailing list. So here goes again. Errors and problems to me. I'll give it 2 weeks and then issue the final version. Nigel Database Working Group Meeting Minutes (Draft 1) RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR Thursday, Sept. 12, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer to take notes received from Nigel) . circulate list of participants, agenda bashing . status of minutes [ see http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html ] . All presentation slides are available on the RIPE NCC web site. B. Action Items . status of actions [AP-41.1 WW] To send list of proposed updates to IRRToolSet to mailing list for WG members to vote on. Deadline 3 weeks. Expired and superceded by AP-43.6 and AP-43.9 [AP-41.2 C&W] To send their proposal to allow referencing external objects in the DB to the mailing list for discussion. Superceded by AP-43.7 and AP-43.8 [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. Ongoing, some work done. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. Complete. IRT objects are being created (4 so far) and no problems being reported with process. [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. Ongoing, no action yet, nothing from Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. Ongoing, no action yet [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. Ongoing. Some work done. [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners using MAIL-FROM Complete. [AP-41.12 RIPE-NCC] Look at general password authentication methods Ongoing. No action yet. [AP-42.1 ALL] To check own data and correct inconsistencies if possible. Closed [AP-42.2 RIPE-NCC] To send instructions on multiple credentials to the DB working group mailing list. Complete. Instructions are now on the RIPE web site. [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow passwords and multiple level authentication schemes. [AP-42.3 Larry Blunk] To investigate the problems of multiple hashed passwords and the possibilities of embedding an ID within the hash and to submit a proposal to the working group. A proposal came from Janos to embed such information in the remarks field. C. DB update (RIPE NCC, Andrei R.) . operations report Statistics Slightly more objects (1.6M) 80,000 users on average 18q/s average, peaking to 65q/s 2 updates per second average Still some growth in unreferenced personal objects. Need garbage collection process. 70% of queries are for contact information Updates pretty average apart from spike in mntner object caused by removal of mail-from authentication Back-end problems solved. Performance issues with long queries is still to be resolved. Otherwise scaling well User support 6 support staff shared with other software projects Introduced anti-spam filter for mail to ripe-dbm (mail routed to folder) since 20th May 2002 Added ripe-dbm ticket system (shared with hostmaster) MAIL-FROM phasing out process. 1500 maintainers missed the deadline. High fax load on DB staff. Robot now in place. Developments New MD5-PW authentication scheme. 41% of maintainers are using it. New status values for intetnum6 are not now generated. DB consistency and statistics project is now generated useful data RRCC full prototype is now up and running IRRToolset. New version 4.7.3 released. Mostly bug-fixes. The database user manual "Getting Started" has been published. (Dummies guide to the RIPE Database). Real Database user's manual is being progresses IRT Document has been published (functionality and procedures) Plans Further improving of server software (Error reporting, performance, and configuration management). Support auth checks across multiple registries IPv6 and multicast support Automatic database cleanup (if object is not referenced then delete after a certain time (following nag messages to user)). There are other possibilities [AP43.1 RIPE NCC] Look at other possibilities for database cleanup. Additional user support (Documentation, Sync and Web interface) Main Events Improvements in security (MD5 and MAIL-FROM) Documentation and User support Web and syncupdate interfaces. D Web interface and Syncupdates for DB (RIPE NCC, Can Bican) Currently updates are via email Hard to automate Difficult for beginner Syncupdates allows online updates to database, web interface built on top of this TCP based Extensible, maintainable, same functionality, easy to use. Minimal client (HTTP) can be used Notifications are sent by email as usual WebUpdates is a prototype of an update client which allows adding, deleting and updating of an object. Only password authentication. Passwords are stored via cookies. No PGP authentication Multi-line attributes not properly handled Only one object may be updated in a submission All suggestions and feature requests are welcomed. http://webupdates-test.ripe.net http://syncupdates-test.ripe.net Probably one month before coming into production (syncupdates) Webupdates can be earlier, but please send comments to the db tools email address. E. Database Consistency Project Statistics (RIPE NCC, Shane) This refers to data that can be seen as incorrect merely by looking at the database itself (eg not routing inconsistencies) Changes in rules Abandoned data User error Examples Non handle admin-c Syntactic errors Missing or incorrect status attributes Unreferenced person objects Unreferenced maintainer objects CSIRT for no networks Unreferenced PGP key Also non-authoritative Data Prehistoric inetnum (non-RIPE) Objects in unprotected space Possibly unauthorized route objects Abandoned objects Unresponsive maintainers (both LIR and non-LIR) Outdated contacts Solutions Reports RRCC reports Database consistency reports Really only helpful for actively maintained objects Restrict Input Many of these checks already but will soon include integrity checks and RPSS checks Does not address current problems Revocation Allow higher level maintainer to delete objects lower in the hierarchy. (Currently can only be done by ripe-dbm). Unresponsive maintainers? Use another maintainer, or delete maintainer? Cleanups RIPE NCC implementation of WG decision Has been done in the past successfully. Discussion Normally starts on the mailing list, generating proposals which are then voted on at the RIPE meeting. Opinions Why spend a lot of resources to clean it up? It will never be completely clean? Only 5% garbage. Difference between structural problems and operational problems. Garbage can prevent the generation of accurate reverse delegation zone files, and address allocation reports. Even 5% garbage can render these useless. Registration of contact information can be really useful, even if not related to operational data. Should we be removing this data if it is useful? However, privacy issues now pertain to this data. We should also be wary of using the DB as a general key-server. F. "Early Registration Transfer" (ERX) Project (Andrei, RIPE NCC) . Introduction ASN and IP registration inherited by ARIN from Internic Pre-RIR Non-geographical . Goals and Phases Transfer of DB records and conflict resolution Transfer of associated documentation Phase 1 ASN registrations Phase 2 IPv4 registration . AS number migration ARIN only (419 ASNs) just created and protected in the RIPE DB Completed 21st August ARIN & RIPE (conflicting data, no RP) (87 ASNs) merge and lock. Resolve conflict and then unlock Completed 21st August ARIN & RIPE (with RP specifications) (177 ASNs) manual 2 week conflict resolution prior to transfer Completed 21st August 30% of notification emails bounced. Lessons Don't use August..... Often no evidence. Makes resolution very difficult in cases of dispute. Do not lock objects. They may be in use. Some people only wake up at the deadline . IP V4 migration 47 /8s to be transferred Conflicts are likely to be more complex. Transfer of DNS reverse delegations. Group 1 (ARIN only) Create and protect in the RIPE DB Group 2 (Exact match between ARIN and RIPE, except for contact and description) Resolve conflicts and then merge (do not lock) Group 3 (RIPE does not match ARIN) If NCC allocation then keep in RIPE Otherwise delete (after response time) . Discussion Thanks for the RIPE NCC from ARIN for their cooperation Human matching of records cannot necessarily be done by machine. Records that obviously match on visual inspection may not be easily matchable automatically. Two weeks (especially in August) is not enough time to resolve conflicts [AP43.3 RIPE NCC] Provide detailed action plan to the WG before implementing Phase 2. Trying to obtain authorization from contacts in the ARIN database is likely to be difficult, as in many cases the authoritative data is the RIPE database. Hence it may be necessary to extend the time for resolution of conflicts. What happens to IPv4 objects that are in an undefined state after the process? They will remain locked until the holder emerges. At which point the appropriate procedures will be invoked. Is there any chance of getting information about what IP objects will be transferred, prior to the actual transfer process? [AP43.4 RIPE NCC] To produce a list of requirements for such a list. Is there a possibility of automatically aggregating eg /24s in the ARIN database to the appropriate aggregated object in the RIPE DB? Probably not, as there don't seem to be many such objects. This will probably be a manual process. A suggestion that more resource be allocated to the IPv4 migration than was allocated to the ASN migration. [AP43.5 WW] Set up a task force to go through some test cases before hand. It should report on the mailing lists (DB and LIR) within 4 weeks. (Wilfried Woeber, Nigel Titley, Joao Luis Damas at least) Are there any requirements from the outside for target dates? No fixed date, but should get it done as quickly as possible. G. IRRToolSet Development Brainstorming (+ external refs?) . how to find out who is using what? A few people are... one at least is using a home-brew set of tools It was noted that those who are using the toolset are using it together with other tools. This may have to be taken into account. Some things are missing eg Support for zebra [AP-43.6 ALL] Those who have requirements to send to IRRToolSet(a)ripe.net What tools do people find useful? [AP-43.9 RIPE NCC] To try and track down some of the outdated references to the IRRToolset out on the web and get them corrected. . External reference Who needs it? Need at a minimum things like AS-sets which are referred to in the RFC. Need a list of things for which it makes sense and those for which it would be insane (Ruediger Volk) The status of external reference in the RPSS RFC is "out of document scope", although a possible mechanism is described. There is a clear need for this, and the C&W registry is using this syntax. It is also needed in order forms etc (and is already included in some forms from some providers). The RPSS working group needs waking up to properly resolve this issue. Should the DB be prepared to accept this syntax? No real performance issues (Andrei) and not a real problem. The RPSL-dist informal proposal suggests a new "registry" object. [AP-43.7 Ruediger Volk] To produce a short report on what would be useful and how to start. [AP-43.8 RIPE NCC] To investigate how much effort would be required to add this functionality to the RIPE DB. Y. Input from other WGs . None Z. AOB: . Organi[sz]ation object proposal Examples would be a local registry which could be well described in such an object. . IRT object There are only 4 such objects. However no one has had problems creating

1 0

TEST database maintenance
by Andrei Robachevsky 01 Oct '02

01 Oct '02

Dear Colleagues, We plan to have a maintenance of our TEST database server on 7 October, starting from 20:00 till 9:00 next day, 8 October. During this time the following services will be unavailable: - TEST database for queries and updates. - Webupdates and Syncupdates prototypes. - RRCC reports and statistics. - DB Consistency reports and statistics. We apologise for any inconvenience this may cause. Regards, Andrei Robachevsky RIPE NCC

2 2

[Internet-Drafts@ietf.org: I-D ACTION:draft-ietf-crisp-iris-areg-00.txt]
by Stephane Bortzmeyer 13 Sep '02

13 Sep '02

Following the short discussion this morning at RIPE-43, here is a I-DI believe we should discuss here. whois sucks :-) ----- Forwarded message from Internet-Drafts(a)ietf.org ----- Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-00.txt From: Internet-Drafts(a)ietf.org Reply-To: Internet-Drafts(a)ietf.org To: IETF-Announce: ;IETF-Announce:; Cc: ietf-not43(a)lists.verisignlabs.com Date: Fri, 16 Aug 2002 07:45:33 -0400 X-BeenThere: ietf-not43(a)lists.verisignlabs.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : IRIS Address Registry Schema Author(s) : A. Newton Filename : draft-ietf-crisp-iris-areg-00.txt Pages : 18 Date : 15-Aug-02 This document describes an IRIS registry id and schema for registered Internet address information. The schema extends the necessary query and result operations of IRIS (draft-ietf-crisp-iris-core-00.txt) to provide the functional information service needs for syntaxes and results used by Internet address registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-iris-areg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-iris-areg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message -----

1 0

Prototype of Whois Server with Revised Parser
by RIPE Database Administration 06 Sep '02

06 Sep '02

Colleagues, The Whois query parser for the RIPE Database Server has been revised to be more consistent and helpful to users. In the new version, inconsistent queries and invalid input will be detected and reported to the user, rather than silently processed. Users may see different results for inproperly formatted queries; some may result in an error message, and some will be processed with an appropriate warning. The idea is to be as clear as possible, but some users may be confused, and tools may break. We would like your feedback on the changes, so that we can modify the behaviour to provide the clearest and most useful results. Accordingly, we are now running a prototype of the Whois server with the revised parser. It is a mirror of the production server, meaning that it will provide the same results for queries, except where the parser is different. Usage: To access this server, use "whois-beta.ripe.net" as your Whois server. Except as noted on the web page below, queries behave identically to the production server. For full details, please see: http://www.ripe.net/ripencc/pub-services/db/whois-prototype-2002.html Feedback: Please send any comments or suggestions to <dbrip(a)ripe.net>, or discuss on the Database Working Group mailing list: http://www.ripe.net/ripe/wg/db/index.html We look forward to your feedback. -- Shane Kerr Database Group RIPE NCC

1 0

webupdates & syncupdates
by Can Bican 06 Sep '02

06 Sep '02

Dear Colleagues, Prototypes for Web Updates and Synchronous Updates have been released, with the announcement available on http://www.ripe.net/db/syncupdates/ . - Web Updates Implementation of "Web Based Updates" intends to help the users of the RIPE Database by providing a convenient and simple to use graphical user interface for updating the database. The graphical user interface combines the help, update and acknowledgement facilities of the database to one graphical user interface. The first prototype is released, available from the url below. Prototype has the minimum functionality to send the updates. Operations currently supported are: * Add/delete/edit objects, * Add/delete/change the order of attributes, * Provide password based authentication, * Help text for each attribute, * Ability to prohibit updates on existing objects, forcing creation. The application can be used from the following URL: http://webupdates-test.ripe.net/ There is also an SSL interface available: https://webupdates-test.ripe.net/ Since this application is currently being developed, your feedback is most important to us. Please send any comments, suggestions, questions and criticisms to dbtools(a)ripe.net. - Synchronous Updates The aim of "Synchronous Updates" is to support updates to the RIPE Database in interactive, or synchronous mode, where the submission and the acknowledgement are communicated synchronously, unlike conventional mail. It also provides a backend for applications like "Web Based Updates". Main goals in developing this tool are: * Compatible with mail updates, having the same functionality, * Easy to program interfaces, * Scalable and controllable, responsive to overuse and/or misuse of resources, For updating the database using the prototype of syncupdates, either use this page: http://www.ripe.net/db/syncupdates/syncupdate-minimal.html or use the perl script, available at: http://www.ripe.net/ripencc/pub-services/db/syncupdates/sup_cli.pl which accepts the update from standard input. Please feel free to send your comments, suggestions, questions and criticisms to dbtools(a)ripe.net. Best Regards, -- Can Bican

1 0

New Document available: RIPE-253
by RIPE NCC Document Announcement Service 05 Sep '02

05 Sep '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-253 Title: RIPE Database User Manual: Getting Started Author: Andrei Robachevsky, Shane Kerr, Vesna Manojlovic Samantha Dickinson Date: 9 September 2002 Format: PS=78771 TXT= Available soon Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document is intended for users who have no previous experience with the RIPE Database. It is a hands-on tutorial that walks the reader through the basic concepts and techniques that are needed to use the RIPE Database using example and exercises. This document is not intended to be a complete reference. Full information on the RIPE Database may be found in the RIPE Database Reference Manual at: http://www.ripe.net/ripe/docs/databaseref-manual.html Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. the "RIPE Database User Manual: Getting Started" is available at the following URL: http://www.ripe.net/docs/db-start.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-253.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-253.txt plain text version Please note that the .txt version will be available as soon as possible. Kind Regards, Jeroen Bet RIPE NCC Webmaster

1 0

draft agenda (v1), for DB-WG meeting, RIPE 43, Rhodes, GR
by Wilfried Woeber, UniVie/ACOnet 26 Aug '02

26 Aug '02

Dear WG list members, attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 43 in Rhodes, GR. As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Greece, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR 1. Draft Thursday, Sept. 12, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) 10 min . scribe (offer to take notes received from Nigel) Slot 1 . circulate list of participants, agenda bashing . status of minutes [ see http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html ] B. Action Items 15 min . status of actions Slot 1 [ see http://www.ripe.net/ripe/wg/db/db-actions.html ] C. DB update (RIPE NCC, Andrei R.) 15..20 min . operations report Slot 1 . development activities D Web interface for updates (RIPE NCC, Can Bican) 15min(??) Slot 1 E. IRRToolSet Development Brainstorming 20min . how to find out who is using what? Slot 1 . RPSLng interaction F. External Object References 10min [ maybe this should go into item E.?? ] G. "Early Registration Transfer" Project 45 min . review of experience with AS Number transfer probably . proposal for IP Address Space by NCC Slot 2 . develop recommendations to - complete the transfer as quickly as reasonably possible? - limit the work-load impact on the users' end - limit the work-load impact on the NCC's end Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 26-AUG-2002 12:13:25 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

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 19 Aug '02

19 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

New Document available: RIPE-243
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "New Values of the "status:" Attribute for inet6num Objects". Short content description ------------------------- This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "New Values of the "status:" Attribute for inet6num Objects" is available from the WWW at the following URL: http://www.ripe.net/docs/new-value-status.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-243.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-243.txt plain text version Kind Regards, Jeroen Bet Webmaster RIPE NCC

1 0

Actions web page
by Nigel Titley 30 Jul '02

30 Jul '02

Folks, Please note that there is now a separate actions page on the DB WG web site. http://www.ripe.net/ripe/wg/db/db-actions.html Check now and avoid embarrassment at the next WG meeting :-) All the best NIgel

1 0

fwd: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects"
by Wilfried Woeber, UniVie/ACOnet 26 Jul '02

26 Jul '02

Sorry, I forgot to cc: the DB-WG list :-( I guess we should keep this thread in the LIR-WG list for the moment. Apologies for the mix-up, Wilfried. ______________________________________________________________________ From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-JUL-2002 11:39:50.52 To: MX%"leo(a)ripe.net" CC: MX%"lir-wg(a)ripe.net",WOEBER Subj: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" Dear Leo and "Team", >The new draft is available from our web site at: > ><http://www.ripe.net/ripe/draft-documents/new-value-status.html> Looks good! >We would welcome comments on this new draft until Thursday, 1 August >2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Procedural question: How are we going to modify existing objects to conform to this proposal? Right now the template query returns: bash-2.05a$ wripe -t inet6num [ ... ] inet6num: [mandatory] [single] [primary/look-up key] [ ... ] status: [generated] [single] [ ] [ ... ] and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: bash-2.05a$ wripe -r 2001:0628::/35 [ ... ] inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: CP8-RIPE notify: Domain-Admin(a)UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster(a)ripe.net 19990920 changed: hostmaster(a)ripe.net 20011019 source: RIPE Is this going to change? E.g. to: status: [mandatory] [single] [ ] The wording used in the draft seems to indicate [optional] [single] [ ]. I think some clarification would be helpful. Thanks, cheers, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0