home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / time / ntp / 1055 < prev    next >
Encoding:
Text File  |  1992-11-22  |  1.2 KB  |  30 lines
  1. Newsgroups: comp.protocols.time.ntp
  2. Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!ra!atkinson
  3. From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
  4. Subject: Re: MIB for ntp
  5. Message-ID: <By4JHo.rD@ra.nrl.navy.mil>
  6. Keywords: MIB SNMP
  7. Sender: usenet@ra.nrl.navy.mil
  8. Organization: Naval Research Laboratory, DC
  9. References: <1992Nov20.154239.27827@den.mmc.com> <1emjakINNmcn@ni.umd.edu> <2B0F17FD.22593@news.service.uci.edu>
  10. Distribution: inet
  11. Date: Sun, 22 Nov 1992 15:39:24 GMT
  12. Lines: 16
  13.  
  14. In article <1emjakINNmcn@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
  15. >There are, of course, a number of design decisions to make; one of the
  16. >more obvious is how to represent 64 bit NTP timestamps in the MIB.
  17. >Two 32 bit integers?  Octet string?  Hmm..
  18.  
  19.   That is a good question.  The notion of adding a 64-bit entity as
  20. part of the SNMP v2 (aka SMP) work seems to have been discarded if I
  21. recall my mailing list traffic correctly.
  22.  
  23.   If such a MIB were read-write, someone would need to look at the
  24. security implications since NTP already has its own security and SNMP
  25. has its own.  It would be undesirable if a compromised SNMP could be
  26. used to undermine an uncompromised NTP or vice versa.
  27.  
  28. Ran
  29. atkinson@itd.nrl.navy.mil
  30.