Dave Katz <> Thu, 23 May 1996 20:43 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01890; 23 May 96 16:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01886; 23 May 96 16:43 EDT
Received: from by CNRI.Reston.VA.US id aa15285; 23 May 96 16:43 EDT
Received: by (5.65c/5.61+local-23) id <AA01648>; Thu, 23 May 1996 13:10:32 -0700
Received: from by (5.65c/5.61+local-23) id <AA01641>; Thu, 23 May 1996 13:10:27 -0700
Received: from by (5.65c/5.61+local-23) id <AA25500>; Thu, 23 May 1996 13:10:18 -0700
Received: (dkatz@localhost) by (8.6.8+c/8.6.5) id NAA16136; Thu, 23 May 1996 13:10:16 -0700
Date: Thu, 23 May 1996 13:10:16 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Katz <>
Message-Id: <>
In-Reply-To: "Louis A. Mamakos"'s message of Thu, 23 May 1996 11:05:10 -0400 <QQaqym04471.199605231505@rodan.UU.NET>
Subject: musings
Precedence: bulk

The cisco version is primarily a port of xntpd (with some creative florishes
due to a different local clock architecture).

Of course, pretty much everybody (including Dr. Mills) has had their hands
on xntpd, so it's hard to really trace the lineage any longer.  But I
think the claim could be made (without *too* much of a stretch) that
in fact three independent, interoperable implementations do exist.

   From: "Louis A. Mamakos" <>;
   References: <9605231347.AA08987@MAILSERV-D.FTP.COM>; 
   Date: Thu, 23 May 1996 11:05:10 -0400
   Sender: owner-rreq@ISI.EDU
   Precedence: bulk

   > Date: Thu, 23 May 1996 09:47:13 EDT
   > To: rreq@ISI.EDU
   > Reply-To:
   > From: (Frank Kastenholz)
   > Subject: Re: musings
   > stev writes...
   >  > >So, my personal recommendation would be to back off from your
   >  > >(laudable) desire for demonstrated interoperability for
   >  > >rreq, and GET ON WITH IT.
   >  > 
   >  > 
   >  > it is not clear to me that, based on the current rules, he *can* get on with
   >  it.
   >  > 
   >  > at some point, as i understand them, the standardization rules require the
   >  > document to be revised to remove everything that has not been implemented in
   >  > *one* implementation. this does not mean *any* implementation. one was
   >  > required to hopefully catch any race  conditions . . . . .
   > RFC1871 -- the variance procedure -- may apply.
   > there is also the historical precedent of ntp -- all ntp seems to be derived
   > from dave mills' original code...

   This is incorrect.

   Mills' original code was written in PDP-11 assemby code for the
   Fuzzball platform.

   At the time that the original NTP protocol spec was being written
   down, Mike Petry and myself , then both at the University of Maryland,
   did a reference implementation based on specification.  This was as
   much a validation of the protocol, as well as the veracity of the
   protocol specification written on paper.  It was a very interesting
   process and we worked closely with Mills in clarifing the written spec
   when implementation questions arose.  There were quite a few drafts
   which were produced at the time.

   The implementation that we did was a "reference implementation" built
   for "comfort, not speed".  It did function, however, quite well, and
   is the basis for code being shipped by some commercial vendors, DEC
   Ultrix and NeXT come to mind.

   Sometime after, Dennis Ferguson, then of the University of Toronto
   undertook his own NTP implementation ("XNTP"), targeted to NTPv2 with
   a somewhat different implementation approach.  It's decendents are now
   the implementation of choice for UNIX platforms.

   There is a quite complete implementation of NTP in Cisco routers,
   which I think may be based on Ferguson's version, but I'm not sure.

   We had multiple interoperable implementions which worked quite well.
   In fact, the dominant implementation which was deployed in far greater
   numbers was either the version that Petry and myself did or later, the
   Ferguson version; the Mills implementation didn't get quite so
   extensive deployment because of the unique platform which it ran on.

   While the process wasn't followed because it didn't exist at the time,
   the spirit of it was because that's what made the IETF standards
   process work.

   (Oh, and the NTP RFC is one which really makes good use of PostScript.
   It makes reading the math in it much easier on the eyeballs.  But I

   Louis A. Mamakos,  Manager, Strategic Technologies,  uunet!louie
   UUNET Technologies, Inc.                            Voice: +1 703 206 5823
   3060 Williams Drive                                 Fax:   +1 703 208 5390
   Fairfax, VA 22031