COMMunities still confusing Dale

Marten, Tony, Daniel,

  I've been working through the final drafts to see if I can figure out
how Communities work, but I'm still having problems.

Ripe-181 still says (p 27):

    The community tags can only be created and updated by the "guardian"
    of the community and not by those directly responsible for the 
    particular network.  This ensures that community guardians remain
    in control of community membership.

This still seems to imply some mechanism with the functionality of a
guardian file, where the owner of the community decides which Route
objects are stamped with the community name.

Auth (p 9) says:

    Note that this rule changes the level of membership control
    exercised by community and AS guardians have with respect
    to the "guardian file" method.  Control is now by notification
    after the fact.

This implies that anyone entering or modifying a Route object can
mark it as belonging to any community he wishes--and that the community
owner just gets email afterword.  It also sounds to me (without further
explanation somewhere) as though someone wanting to create a new
community would have to find all of the owners of all of the routes
that should belong to that community, and would have to contact them
out-of-band with messages saying "I've just created this new community
COMM_GOODGUYS, would you mind editing all of the following routes to
include COMM_GOODGUYS in their comm-list attribute?".  To create the
NSFNET community in your example, we would have to make out-of-band
requests to the 464 ASs that are currently submit have registered
NSFNET routes in the PRDB, asking each of them to modify their entries
for us.  It would also imply that the Guardians still need to keep a
file of who they think *should* be members of their community, though
now this file has moved from being a Guardian File hosted on a Routing
Registry machine to being something that keep privately for their own
use.

Am I still misunderstanding?  Is there a section of the new drafts that
I've missed, or a new document that will explain this that will be out
soon?  Sorry to be pushy on this;  we need to be coding this functionality
this week in order to configure the Route Servers, and we're trying as
hard as we can to do it within the RIPE-181 framework.

If I do have this right, the Community structure seems unusable for
storing net lists for use in local configuration generation.  The best
solution I can see for adding the functionality we need would be the
one Rick suggested Friday:  add a new object for that purpose which
could be used with the experimental DBSELECTOR to come up with specific
net lists.  This is essentially what Laurent has implemented in alc,
except that those lists are in private files that only alc knows about,
rather than being part of the Routing Registry that is visible through
whois, ftp dumps, etc.  Again, assuming I'm not still misunderstanding
the new community implementation, does this sound like the most
RIPE-181-like implmentation we can come up with for storing local
routing info for our 40K registered routes, while still making that
information available as part of the registry?  Any other ideas?

--Dale




-------- Logged at  Sun Sep 18 20:41:18 MET DST 1994  ---------