A Modest COMMunity Proposal

 *   PROPOSAL:  That the RIPE DB code that reads COMMUNITY files be written
 * in such a way that only the IP/LEN at the beginning of each line be read;
 * that anything after that initial IP/LEN (and trailing whitespace) would
 * be considered as a comment by existing code.
 * 
 * 
 * 
 *   COMPLICATED RATIONALE:  We have this "DBSELECTOR" thing that we need

[..]

I sort of understand the rationale. I'll have to go through it in a
bit more detail though especially in light of:

 * But since you are finishing up the next release of the code, I thought
 * I'd suggest the addition of the one inoccuous line to the code that reads
 * COMMunity files that would keep this approach from breaking things in the
 * future.

The next release of the code will no longer work with the guardian
files stuff the way they do now. I am sorry we have not been too
informative about this, but this sort of came out of an authorisation
document written only last week. Some bits were agreed at the RIPE
meeting. What it basically comes down to is that each and every object
can be properly maintained, ie there is some authorisation done before
an object can be updated. For routes, the usual maintainer would be
the person currently being the guardian. They insert the route, so
they change the object, and them only. Communities are no longer
guarded as such, but are being put in a special position, so that
every change to a route that affects communities, all community
guardians receive a notification of this change. For a bit more
detail, you should have a look at:

ftp.ripe.net:ripe/drafts/ripe-auth.{txt|ps}
ftp.ripe.net:ripe/drafts/db-trans.{txt|ps}

The first explains the general authorisation model and the way it can
replace the current guarded attributes and guarded objects mechanism
(which I always considered an interim measure), and the second
provides a transition plan (mostly for us) to move to ripe-81++ and
classless database with all consequences involved.

These docs have just been finished so you probably have not seen them
yet. Mind you, they will have to be agreed at the RIPE meeting next
week. We see little problems though.

In the meantime, let me think about the rest of your mail. If you just
want a quick change to skip everything in the cleanup after you have
read the prefix/length, that is easy. In cleandb.pl in the routine
readguard(), some 20 lines down from the top or so, you'll find the
regex substitution 

s/\s*$//;

which removes all trailing spaces. Change that to something like:

s/^(\S+).*$/\1/;

and it should ignore everything after the first string. Come to think
of it, it does not even strip leading spaces. Bug ;-( Better make
that:

s/^\s*(\S+).*$/\1/;

that should work. The rest of the community detail stuff I'll have to
read better first.

Adios,

-Marten



-------- Logged at  Thu Sep 8 22:02:29 MET DST 1994  ---------