 the Time to Live [TTL] was set to zero). This made PTPv1 unsuitable for a WAN deployment but fine around the factory floor or across a laboratory. The Network Time Protocol (NTP), on the other hand, was ideal for synchronization of widely dis- tributed computing systems and was almost always routed. The use case for NTP is to allow all the routers in a network, every laptop on a college campus, or the home router on your broadband con- nection to align their time of day. One example where this is important might be to align the syslog timestamps of many machines, which is a necessary precondition to effectively find and trace faults across a network. For current usage, the most prevalent deployments of NTP are used to deliver time synchronization down to the millisecond level. In contrast to the IEEE defining IEEE 1588, it was the Internet Engineering Task Force (IETF) standards development organization (SDO) who developed NTP through its Request for Comment (RFC) process. NTP had been specified starting in the mid-1980s (RFC 958) and is now at version 4 (RFC 5905)-so it is a very mature technology. See the following link for further details on the IETF process for creating Internet standards: https://www.ietf.org/standards/process/ There is also a somewhat simplified version of NTP known as Simple Network Time Protocol (SNTP), which has less-demanding requirements for accuracy and reliability than NTP. SNTP is fine for simply updating the clock on remote machines, but its simplified approach leaves out fea- tures that might be desired. For example, it does not have continuous system clock adjustment methods, normally used to prevent steps and jumps in the clock, but for everyday usage (such as your home laptop) it is perfectly adequate. SNTPv4 is specified in RFC 4330, although that func- tionality has now been folded into the single NTPv4 specification in RFC 5905, thereby obsoleting RFC 4330. NTP was typically implemented only in software, which limited the potential accuracy it could achieve, whereas PTP was