Suggestion about foreign NIC-HDL in Whois

All,

As I was complai^Wtalking about Whois with a collegue last night (hi
Ambrose!), I thought of an alternate method of handling foreign keys.

Note on nomenclature:

  "local" means in the Whois database of the server being queried
  "foreign" means in the Whois database of a different server
  "object" means database record
  "key" means attribute of the record, usually a NIC-HDL

To date, my thoughts have been:  "If I have a reference to a foreign
object, and something happens to that object, I am hosed."  A sample
object from the RIPE database as an example:

inetnum: 192.168.1.0 - 192.168.1.255
netname: NET-TEN-HUT
descr:   A horse is a horse, of course, of course.
country: NL
admin-c: BOBS-ARIN
tech-c:  MARYK-ARIN
status:  ASSIGNED PA
mnt-by:  SHANE-MNT
changed: [email protected] 20010221
source:  RIPE

If BOBS-ARIN gets deleted, suddenly there is no administrative contact
information.  This can be prevented for objects in the same database,
but for foreign objects, preventing this is Very Difficult, as I tried
to express in previous e-mails.

However, it occurred to me that this isn't really the problem that I
thought it was.  The person who is responsible for this inetnum object
is the one who is also responsible for keeping it up to date.  Rather
than PREVENT the inconsistencies, we simply need to FIX them.

A server needs to:

1. Detect inconsistencies.
2. Fix inconsistencies.
3. Insure required relationships are maintained.
4. Help database users maintain these relationships.

In more detail:

1. Detect inconsistencies

  What I propose is that the Whois server verify the accuracy of a
  foreign object whenever a user attempts to access it.  This occurs:

  A. When a foreign key is added to a local object.
  B. When a local object with a foreign key is queried.

  So when an object is created and a foreign object is
  referenced, the server needs to at that time verify the object exists.
  If it does not, then the database modification should be refused.

  Further, when a client queries and object with a reference to a
  foreign object, then it should verify that the foreign object exists
  at that time.  If it does not, then an inconsistency has occurred and
  needs to be fixed.

  An update can be treated by verifying the new object, and if it fails,
  proceed to verify the old object as on query.

2. Fix inconsistencies

  If an inconsistency is detected, then it must be resolved.  The
  easiest way to do this is to delete the attribute that references the
  missing data.  Additional modifications to the object may be
  necessary, depending on the database (e.g. "changed" attribute added
  or a "remark" appended).

  Since most of the time this will occur during a query, this should be
  done transparently.  That is, if I have a tech-c that is invalid, the
  rest of the attributes of the object should be returned to the query.

3. Insure required relationships are maintained.

  Unless done carefully, this automatic updating of objects may lead to
  invalid database states.  For example, in the NET-TEN-HUT inetnum
  object above, if the BOBS-ARIN object is deleted, then an attempt to
  remove the admin-c attribute will result in a required attribute no
  longer being present.  This can be prevented by adding additional
  logic to the creation of objects. 

  In the case of RPSL objects, I suggest that this may be as simple as:
  "If all references to objects not stored locally are deleted, the
  object must still be valid."  So a revised version of the sample
  object might be:

inetnum: 192.168.1.0 - 192.168.1.255
netname: NET-TEN-HUT
descr:   A horse is a horse, of course, of course.
country: NL
admin-c: BOBS-ARIN
admin-c: SHANE-RIPE
tech-c:  MARYK-ARIN
tech-c:  SHANE-RIPE
status:  ASSIGNED PA
mnt-by:  SHANE-MNT
changed: [email protected] 20010221
source:  RIPE

  This allows database operators to guarantee they will have valid
  information about their records, even if all foreign objects are
  deleted.  It is not as flexible as using foreign keys in the same way
  as local keys, but at least it allows their use.

4. Help database users maintain these relationships.

  A database that operates in this fashion should alert users to changes
  in their objects so they can update them accordingly if need be.  For
  example in the sample object above, if MARYK-ARIN is deleted, then the
  maintainer of the object, SHANE-MNT, would be sent an e-mail
  documenting this.

  I would suggest that databases should keep a copy of the most recent
  version of the foreign object to be sent to the user.  In this case,
  the user would get an e-mail like, "A record from the ARIN database
  called MARYK-ARIN has been deleted.  It was referenced by NET-TEN-HUT.
  The latest information we had was: ...".

One possible implication of this approach is a lot of extra Whois
queries between servers if it becomes popular.  In this event, a cache
mechanism could be employed, with the usual benefits and caveats.

This approach will prevent the possiblity of broken references, or the
need for servers to create objects without a user requesting it (one of
the proposed solutions to the problem).

Thoughts?

--
Shane