Dear Dale, * "Dale S. Johnson" <dsj@merit.edu> writes: * Steve, * * > Who will act as coordinator to get this stuff distributed? I assume * > that the RA in the U.S. can take the lead in this role if we were to * > provide source. * * The only thing close to an official answer to this question at the moment * is that RIPE is the home and custodian of the official distribution * source. * * At the RA, we've been trying rather hard to minimize any modifications to * RIPE code, if only to simplify importing further revisions of their code. Thank you ! * (But not making modifications is getting harder, as we get user pressure * to make email address parsing case-insensitive, add PGP, [add inet-rtr * support, if we aren't just looking for it in the wrong places today], * etc). I think that most of things you mention here are exactly the same as the wishlist of the RIPE community so for that there is no need for a divergence ;-) The inet-rtr support is there, although it is not very visible since it uses only generic attributes as admin-c and others. Please note that you forgot a colon after the admin-c attribute in your previous mail. After adding that the inet-rtr object was properly updated : ------------------------------------------------------------------------ Update OK: [inet-rtr] nss11.ans.net Delete OK: [inet-rtr] nss11.ans.net ------------------------------------------------------------------------ * The RA does post the radbserver (rpslserver) and RtConfig tookkit * distributions, which are separable packages from the RIPE distribution. * If we were to package and post our own "RIPE-181-modified by the RA" * distribution today, there might be some considerable confusion. * * The RA is generally willing to install Curtis' changes in our * implementation, though this needs discussion with the list since * our accepting such non-181 syntax would probably break implementations * and/or tools of other registries (such as RIPE itself) which import * that data and make it available to their tools (like prtraceroute). (Syntax) changes (not the implementation details!) are normally discussed in the RIPE database working group. After we reach consensus the changes will be implemented. I would strongly ask you all to join the discussion on the <db-wg@ripe.net> as that is probably the most appropriate platform to discuss these issues. For example the case-sensitive E-mail parsing could be changed if our contributors and you all ask for it ! * Clearly this all needs sorting out. (Maybe starting in the halls at * NANOG?) But for the moment, the answer is that RIPE is the custodian. I hope to see you all in the halls ;-), Kind regards, David Kessens RIPE NCC Database maintainer ----------- * ============ From: Steve Heimlich * * > From heimlich@ans.net Mon May 15 21:21:43 1995 * > To: "Dale S. Johnson" <dsj@merit.edu> * > Cc: cengiz@isi.edu, curtis@ans.net, Tony.Bates@ns.mci.net, rr-impl@ripe.ne * t, * > selina@ans.net * > Subject: Re: just an FYI - don't panic * > Date: Mon, 15 May 1995 21:20:44 -0400 * > * > Dale, * > * > Who will act as coordinator to get this stuff distributed? I assume * > that the RA in the U.S. can take the lead in this role if we were to * > provide source. * > * > Thanks, * > Steve * > * > > > Is it OK if I added about 4 lines of code in enparse.pl to do Unix * > > > style backslash at the end of the line continuation? * > > * > > This is a great idea; I think it should be done. But... * > > * > > in order for this idea to be completely implemented, the change has to * > > be installed in Amsterdam, Reston, and Toronto as well as Ann Arbor; * > > and probably several places (ESNet, DSI, NASA, APNIC) that we aren't * > > sure of yet. * > > * > > Also, is enparse.pl part of any of the tools? Then it needs to be * > > changed in all the copies of those tools that anyone has FTP'd as * > > well.