status of ndb working group

Edward Vielmetti <> Wed, 11 March 1992 07:01 UTC

Received: from by ietf.NRI.Reston.VA.US id aa25304; 11 Mar 92 2:01 EST
Received: from by NRI.Reston.VA.US id aa07776; 11 Mar 92 2:02 EST
Received: from by NRI.Reston.VA.US id aa07772; 11 Mar 92 2:02 EST
Received: from by (5.61/UCD2.04) id AA29929; Tue, 10 Mar 92 22:46:38 -0800
Received: by (5.61/UCD2.04) id AA23369; Tue, 10 Mar 92 22:32:58 -0800
Received: from by (5.61/UCD2.04) id AA23050; Tue, 10 Mar 92 22:22:12 -0800
Received: by (/\==/\ Smail3.1.22.1 #22.11) id <>; Wed, 11 Mar 92 01:18 EST
Message-Id: <>
Subject: status of ndb working group
Date: Wed, 11 Mar 92 01:18:53 -0500
From: Edward Vielmetti <>

Based on a review of the traffic to date on this list I would like
to note a few things which make me rather unhappy about progress to date.

- There is an existing industry group working on remote access to 
  SQL databases (using ISO protocols, but that can be forgiven :),
  which appears to have widespread cooperation from a number of
  database vendors, which has not been helped by IETF NDB.
- There is another existing industry / academic group working on
  a more abstract remote access protocol using Z39.50 (also using
  ISO protocols, but that can be forgiven :) which has widespread
  cooperation from library and internet researchers, which also
  also not been helped by IETF NDB.
- The sole apparent purpose of IETF NDB is to codify a single
  implementation of a remote SQL system produced by a single vendor (IBM).

That is a sad state of affairs.

All else being equal I'd recommend this course of action:

- Abandon the NDB draft as a standards-track RFC.  Of course it could
  be published as an informational RFC but there appears to be no
  compelling reason to bless it as a standard.
- Find an IETF observer (I believe the technical term is "snitch" :-)
  to report fairly on the industry efforts to do remote SQL over ISO,
  as described on this list, and assess whether they are close enough
  to implementation and agreement to try to adapt these efforts to a
  TCP solution.
- Find an IETF observer to report fairly on the progress of the Z39.50
  Implementor's Workshop and try to bring something back from there
  which could be turned into an RFC as well.

The alternative is to disband this working group and acknowlege that
the real work in network database systems is going on outside of
IETF, or perhaps even to note that network databases except where they
collide with network directory services are out of the traditional
realm of problems which require an IETF solution.

Edward Vielmetti, vice president for research, MSEN Inc.
      MSEN Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 741 1120
"using barbed wire for overhead lines and bottlenecks for insulators"