DB User Intf Proposal

Marten,

  'Just some thoughts for your brainstorm (in case any of these are non-
obvious):

  1)  The ability to use the whole Unix environment to support your guardian
      file is really wonderful (vi, emacs, diff, perl, ftp, RCS, ..., ... )

  2)  Login access is troublesome;  rash access eliminates a lot of the
      advantages of having a Unix environment.

  3)  The ability to support full-screen interfaces for new or
      infrequent users is good.  (20% of our NACRs come through the
      full-screen Auto-NACR, and the quality of those is *much* higher
      than the stuff that is emailed.  But then again we haven't
      implemented automatic email parsing and bouncing yet, which the
      RIPE software has.)

  4)  Free, ubiquitous, standard clients are great.  (e.g. whois, mosaic).

  5)  There is a ned for authentication.  This is a well-studied problem.
      It would be good to support a range of authentication methods,
      especially including new ones as they develop.  (local passwords,
      .rhost-like restrictions, pem, kerberos, soft-key, etc).  Possibly
      each object's owner could select which security level he wanted
      for the object (thought that's kind of extreme).  Users need to
      be able to maintain their own authentication registrations (e.g.
      passwd;  adding new registered users to the account; etc.)  The more
      of this that comes for free by piggybacking on some existing client,
      the better.  (Too many options are a real problem, too, of course,
      besides being a pain to maintain).

We were tossing around one model after thinking about Rwhois:  suppose
there was an option for the guardian file to be a pointer to an anonymous
ftp file on the user's machine?  Or to a user's rwhois client?  The 
Registry would then go grab this file once per night or once per use
or some such (and default to the previous night's copy if the new
one was unavailable).  The user would have total control and total use
of his native environment.

Are guardian files retrievable by whois?  (Could/should they be?)  

If there was a good, authenticated, standard, way to send a single named file
to a named machine, that would nearly give us what we need.  Users would
maintain their data on their own machines, and then type:

     pr_update_guardian  AS237  my_as237_guardian_file

that would submit it to the database.  Underneath, this would use mail
or rcp or ftp or pem, with the right authentications, etc.  The world
really needs a version of rcp/rexec that specifies an exact list of
commands that would be accepted, to keep the security hole small.  Uucp 
used to have this, I think.

Just some thoughts for the hopper...  This is a great discussion to have.

-Dale

> I am in the middle of a brainstorm session on the whole guarded
> attribute/object procedure, because I think it can and has to be done
> different. Expect some ideas tomorrow or Friday. I want to get some
> feel on what the right direction for the implementation for the
> principle of guarded information should be.
> 
> Cheers,
> 
> -Marten



-------- Logged at  Thu May 19 13:48:26 MET DST 1994  ---------