[6bone] 6bone pTLA 3FFE:401C::/32 allocated to T-NET

[Jeroen Massar]

-----BEGIN PGP SIGNED MESSAGE-----

Pim van Pelt [mailto:pim@ipng.nl] wrote:

> Hi Jeroen,
> 
> | If wanted, I could do some cleaning in the 6bone database.
> | The plan for doing it and the tools are near-ready.
> | If this is wanted, please give a notice and I'll start working on it.
> | Would be a good thing to have a clean 6bone database, which then at
> | least would show people that it is being looked after.
> I have always supported this initiative. We may be able to 
> gain valuable
> expertise and detect operational pitfalls if we clean up 'a whois
> database'. Perhaps your work can be used to help clean up RIPE/ARIN
> databases too at some point in time.
> 
> If you have any methodology you'd like to share with the 
> list, please go ahead. Or, simply copy the database, clean it up privately 
> and present a diff to the list.
> 
> I agree that the database is being neglected by many folks. Perhaps we
> can reinstate some basic sanity....

We could take the current 6bone database and clean it up a lot
by doing at least the following things:

 - check all objects for valid maintainers.
   - if an object doesn't have a maintainer mail the e-mail addresses
     and check them for validity.
     "This is the 6bone DB Cleaning service, if you read this message
      please attach a maintainer object to <handle> or remove the object
      Objects that don't have a maintainer in <n> days will receive a
      default maintainer"
   - purge if none of the email addresses are valid.
   - add default maintainer when no response in <n> days.

 - don't allow any unmaintained objects to be inserted anymore

 - notify and possibly later purge all ipv6-sites using private ASN's.

 - mnt-lower support
   Insert mnt-lower's for the pTLA's and the currently existing
   inet6num's with the maintainers they have.
   inet6num's without maintainers get the maintainer from the
   level above, also allowing the real owners of the TLA to
   modify them if they want.

 - Removal of all old prefixes (5000::/8 or something?)

A second phase could also include checking:
 - references of objects, though I am quite sure that many
   objects exist for usage in remote places, eg SixXS uses
   the person objects which are mostly unreferenced by the
   rest of the database.

If wanted I could create a program which does all of the above
and then we could have a nice cleaning celebration the next RIPE
meeting. People are urging to clean up odd objects in the RIPEdb
also thus having a clean 6bone db seems like a good idea.

As for having a lot of maintainers, we could even create a
special "MNT-PASSWORD" which allows changing objects using a
per-object password. I envision something like:

person:       Ernest. X. Ample
address:      ExampleCity
e-mail:       test@example.com
nic-hdl:      TEST-EXAMPLE
remarks:      PASSWORD: $1$19e017c9c26a8af449440dae3a6b0aad
notify:       test@example.com
mnt-by:       MNT-PASSWORD
changed:      test@example.com 20031125
source:       6BONE

Then they can manage the object like it is theirs through
the site by sending:

person:       Ernest. X. Ample
address:      ExampleStreet
address:      ExampleCity
e-mail:       test@example.com
nic-hdl:      TEST-EXAMPLE
remarks:      PASSWORD: $1$19e017c9c26a8af449440dae3a6b0aad
notify:       test@example.com
mnt-by:       MNT-PASSWORD
changed:      test@example.com 20031125
source:       6BONE
password:     P455W0RD

Retrieving forgotten passwords could be handled by sending
a new "PASSWORDRECOVER" operation, which would then send
an email to the user with their new password.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP8ODtymqKFIzPnwjEQLjuACgrWLZJ6AYWLS4oxDVw/vN5Ic6k98An0+y
L/QB+yAQmo1xwoKIKC5Cz3rE
=ctG6
-----END PGP SIGNATURE-----