RFC 1769
Simple Network Time Protocol (SNTP)
Simple Network Time Protocol (SNTP) 🌸
okay bestie, this is RFC 1769, and the title block is giving old-school internet energy 🧚. It's from the Network Working Group, written by D. Mills at the University of Delaware, dated March 1995. It's Informational, so it's sharing info with the community, not setting an official standard. It also obsoletes 1361 (RFC-1361, same title), so that older version is replaced by this one 💅.
Status of this Memo ✨
ngl this part is pretty chill 🫶. This memo is here to provide information for the Internet community. It does not specify an Internet standard of any kind, and distribution is totally unlimited 🌈.
Abstract 🦋
Okay so the main character here is the Simple Network Time Protocol (SNTP) 👑. It's a lighter version of the Network Time Protocol (NTP), which is what computers use to sync their clocks across the Internet. SNTP is for when you don't need the full NTP performance and don't have to flex that much accuracy 🍓. It can run in unicast (point to point), broadcast (point to multipoint), and IP multicast mode (where that's available) ✨.
The big idea is that SNTP doesn't change NTP at all. No changes to the current or older versions, no changes to known implementations. It's just clarifying some design features of NTP so it can work as a simple, stateless remote-procedure call (RPC) mode. The reliability and accuracy it aims for are similar to the UDP/TIME protocol in RFC-868 🎀.
This memo replaces RFC-1361, which had the same title. This one exists to explain the protocol model for broadcast mode, add clarification in a few places, and fix some typos 💖. You don't need to know the NTP Version 3 spec (RFC-1305) to implement SNTP, and yes, distribution is unlimited, we love that for us 🙌.
1. Introduction 💅
So, RFC-1305 [MIL92] is the NTP spec, and it's the reason computer clocks across the Global Internet are synced 🌍. It has full mechanisms for accessing national time and frequency dissemination services, organizing the time-synchronization subnet, and adjusting the local clock on each participating peer. Today, NTP gets you accuracy of about 1-50 ms, depending on the synchronization source and the network paths ⏰.
RFC-1305 describes the NTP protocol machine using events, states, transition functions, and actions 🧠. It also has optional algorithms that improve timekeeping quality and help sort through several possibly faulty sync sources. To get accuracy in the low milliseconds across big chunks of the Internet, those intricate algorithms (or their functional equivalents) are necessary 🔥. But honestly? A lot of the time you don't need that level of accuracy. Something in the order of large fractions of a second is fine 😌. That's where simpler protocols like the Time Protocol [POS83] come in. They usually work as an RPC exchange: the client asks for the time of day, and the server replies with it as seconds past some known reference epoch 🧚.
NTP is built for clients and servers with a wide range of capabilities, across a wide range of network delays and jitter 🦋. Most people on the Internet NTP sync subnet use a full software package with every NTP option and algorithm. Those are pretty complex, real-time applications 😭. The software runs on everything from supercomputers to personal computers, but its size and complexity just aren't right for lots of applications. So it makes sense to explore other access strategies using way simpler software for less demanding accuracy needs 💜.
This memo describes SNTP, a simplified access strategy for servers and clients using NTP as it's specified and deployed on the Internet today 🎀. Nothing about the protocol or the implementations running now (or likely to be implemented soon) is changing. The access paradigm is the same as UDP/TIME, so it should be really easy to adapt a UDP/TIME client, say on a personal computer, to use SNTP instead 🫶. SNTP is also designed for a dedicated server setup with an integrated radio clock. If you're careful about controlling the various latencies in the system (which is doable in a dedicated design), you can deliver time accurate to the order of microseconds ✨🔥.
Here's the important part, bestie: SNTP should only be used at the extremities of the synchronization subnet 🚨. SNTP clients should operate only at the leaves (highest stratum) of the subnet, and only in configurations where no NTP or SNTP client depends on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet, and only where no source of synchronization other than a reliable radio clock is available 📻. Full reliability, the kind you'd normally expect from primary servers, only happens with the redundant sources, diverse subnet paths, and crafted algorithms of a full NTP implementation 💀. That also covers the primary sync source itself, like multiple radio clocks and backup paths to other primary servers in case the radio clock fails or delivers incorrect time. So using SNTP instead of NTP on primary servers should be carefully considered, periodt 🙈.
2. Operating Modes and Addressing 🎀
Like NTP, SNTP can run in either unicast (point to point) or broadcast (point to multipoint) mode 🦋. A unicast client sends a request to a server and expects a reply, and from that reply it can figure out the time and, optionally, the roundtrip delay and local clock offset relative to the server. A broadcast server periodically sends a message to a designated IP broadcast address or IP multicast group address, and usually doesn't expect any requests from clients. A broadcast client listens on that address and usually doesn't send requests to servers 📡. Some broadcast servers may choose to respond to client requests too, along with their unsolicited broadcasts. And some broadcast clients may choose to send requests only to figure out the network propagation delay between the server and the client 🧠.
In unicast mode, the client and server IP addresses are assigned the usual way 💅. In broadcast mode, the server uses a designated IP broadcast address or IP multicast group address, together with a designated media-access broadcast address, and the client listens on those addresses ✨. An IP broadcast address has scope limited to a single IP subnet, because routers don't propagate IP broadcast datagrams 🚧. For Ethernets, for example, the Ethernet media-access broadcast address (all ones) is used with an IP address made of the IP subnet number in the net field and all ones in the host field 🍓.
An IP multicast group address is totally different, though, bestie 🌈. Its scope can reach potentially the entire Internet. The actual scope, group membership, and routing are decided by the Internet Group Management Protocol (IGMP) [DEE89] and various routing protocols, which are outside the scope of this document 🧚. For Ethernets, for example, the Ethernet media-access broadcast address (all ones) is used with the assigned IP multicast group address of 224.0.1.1 💜. Apart from the IP addressing conventions and IGMP, there's no difference in server operations between an IP broadcast address and an IP multicast group address 🫶.
Broadcast clients listen on the designated media-access broadcast address, like all ones on Ethernets 👂. For IP broadcast addresses, nothing else is needed. For IP multicast group addresses, the host may need to implement IGMP so the local router intercepts messages sent to the 224.0.1.1 multicast group 🎀. Those considerations are beyond this document's scope, so we're leaving them there 🙈.
🚨 Security alert, not gonna lie this is a big one: SNTP multicast clients are genuinely vulnerable to being disrupted by misbehaving or hostile SNTP or NTP multicast servers elsewhere on the Internet. Right now, every one of those servers uses the same IP multicast group address, 224.0.1.1 😭. Where it's needed, access control based on the server source address can be used to pick only the servers the client knows and trusts 🔒. There's also an informal convention: NTP multicast servers now include an MD5-encrypted message digest in every message, so clients can check that a message is authentic and wasn't modified in transit 🔐. SNTP clients could, in principle, implement the necessary encryption and key-distribution schemes, but that's considered unlikely for the simple systems SNTP is meant for 💀.
Even though it's not part of the SNTP spec itself, the plan is that IP broadcast addresses get used mainly in IP subnets and LAN segments with one fully functional NTP server and a bunch of SNTP clients on the same subnet 🏠. IP multicast group addresses are meant only for special cases engineered on purpose 🔥. Specifically, SNTP servers should use IP multicast group addresses only if the server implements the NTP authentication scheme from RFC-1305, including support for the MD5 message-digest algorithm 🦋.
Part 1 is done, bestie! Part 2 is next, and we're getting closer to the good stuff 👀🫶
3. NTP Timestamp Format ✨
okay so SNTP uses the standard NTP timestamp format from RFC-1305 and the earlier versions of that doc 🦋 In line with normal Internet practice, NTP data are specified as integer or fixed-point quantities. Bits are numbered big-endian style, starting from 0 on the left, which is the high-order side 💅 Unless something says otherwise, every quantity is unsigned and can use its whole field width, with an implied 0 sitting in front of bit 0 🎀
NTP timestamps are literally the main product of the protocol, so they get their own special format 😭 They're a 64-bit unsigned fixed-point number, counting seconds from 0h on 1 January 1900 ⭐ The integer part lives in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low-order bits should be set to 0. This layout makes multiple-precision arithmetic easy and converts neatly to the UDP/TIME representation (seconds), but it makes the ICMP Timestamp message representation (milliseconds) a bit messier 🙈 The precision is about 200 picoseconds, which should be adequate for even the most exotic requirements 🔥
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the tea 🍓 Since some time in 1968, the most significant bit (bit 0 of the integer part) has been set, and the 64-bit field will overflow sometime in 2036. If NTP or SNTP is still in use in 2036, some external means will be needed to tell time relative to 1900 apart from time relative to 2036 (and other multiples of 136 years). Timestamped data that needs that sorting will be so precious that the right tools should be readily available 🌸 Every 136 years there's a 200-picosecond interval, which we're going to ignore, when the 64-bit field will be 0. By convention, that's read as an invalid or unavailable timestamp 🧚
4. NTP Message Format ✨
so NTP and SNTP are both clients of UDP [POS80], which is itself a client of IP [DAR81] 💖 The IP and UDP headers are described in those cited specs, so we won't go over them again here. The UDP port number for NTP is 123. It should be used in both the Source Port and Destination Port fields of the UDP header. The other UDP header fields should be set the way the specification describes 🫶
Next up is the SNTP message format. It sits right after the IP and UDP headers, and it's basically identical to the NTP format in RFC-1305, except some of the data fields are "canned," which means they start out with pre-specified values ✨ Here's what the NTP message looks like:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authenticator (optional) (96) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+As the next section explains, most of these fields are filled with pre-specified data in SNTP. For completeness, here's a quick rundown of what each field does 💜
Leap Indicator (LI): This is a two-bit code that warns about an upcoming leap second to be inserted or deleted in the last minute of the current day. Bit 0 and bit 1 are coded as follows:
LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)Version Number (VN): This is a three-bit integer for the NTP version number, which is currently 3 ✨
Mode: This is a three-bit integer for the mode, with the values defined like this:
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private useIn unicast mode, the client sets this field to 3 (client) in the request, and the server sets it to 4 (server) in the reply. In broadcast mode, the server sets this field to 5 (broadcast) 📡
Stratum: This is an eight-bit unsigned integer for the stratum level of the local clock, with values defined like this:
Stratum Meaning
----------------------------------------------
0 unspecified or unavailable
1 primary reference (e.g., radio clock)
2-15 secondary reference (via NTP or SNTP)
16-255 reservedPoll Interval: This is an eight-bit signed integer for the maximum interval between successive messages, in seconds, rounded to the nearest power of two. The values that can show up here currently range from 4 (16 s) to 14 (16284 s). Most applications only use the sub-range 6 (64 s) to 10 (1024 s) 🍭
Precision: This is an eight-bit signed integer for the precision of the local clock, in seconds, rounded to the nearest power of two. The values that normally show up here range from -6 for mains-frequency clocks to -20 for microsecond clocks found in some workstations 💅
Root Delay: This is a 32-bit signed fixed-point number for the total roundtrip delay to the primary reference source, in seconds, with the fraction point between bits 15 and 16. Heads up, this variable can be positive or negative, depending on the relative time and frequency offsets. The values that normally show up here range from negative values of a few milliseconds to positive values of several hundred milliseconds 🎢
Root Dispersion: This is a 32-bit unsigned fixed-point number for the nominal error relative to the primary reference source, in seconds, with the fraction point between bits 15 and 16. The values that normally show up here range from 0 to several hundred milliseconds 🌈
Reference Clock Identifier: This is a 32-bit code that identifies the specific reference source. For stratum 0 (unspecified) or stratum 1 (primary reference), it's a four-octet, left-justified, 0-padded ASCII string. The NTP spec doesn't list these, but here are some representative ASCII identifiers 🧸
Stratum Code Meaning
----------------------------------------------------------------
1 pps precision calibrated source, such as ATOM (atomic
clock), PPS (precision pulse-per-second source),
etc.
1 service generic time service other than NTP, such as ACTS
(Automated Computer Time Service), TIME (UDP/Time
Protocol), TSP (Unix Time Service Protocol), DTSS
(Digital Time Synchronization Service), etc.
1 radio Generic radio service, with callsigns such as CHU,
DCF77, MSF, TDF, WWV, WWVB, WWVH, etc.
1 nav radionavigation system, such as OMEG (OMEGA), LORC
(LORAN-C), etc.
1 satellite generic satellite service, such as GOES
(Geostationary Orbit Environment Satellite, GPS
(Global Positioning Service), etc.
2 address secondary reference (four-octet Internet address of
the NTP server)Reference Timestamp: This is the time the local clock was last set or corrected, in 64-bit timestamp format 🕰️
Originate Timestamp: This is the time the request left the client for the server, in 64-bit timestamp format 🚀
Receive Timestamp: This is the time the request arrived at the server, in 64-bit timestamp format 📥
Transmit Timestamp: This is the time the reply left the server for the client, in 64-bit timestamp format 📤
Authenticator (optional): When the NTP authentication mechanism is implemented, this field holds the authenticator information defined in Appendix C of RFC-1305. In SNTP, this field is ignored for incoming messages and is not generated for outgoing messages 🔐
5. SNTP Client Operations ✨
okay bestie, so the whole vibe here is that an SNTP client is basically an RPC client with zero persistent state 💅 🧚 no memory, no drama. 🫶 In unicast mode it sends a client request (mode 3) and waits for a server reply (mode 4). In broadcast mode it doesn't send anything at all 🙈 it just listens for broadcast messages (mode 5) from one or more servers, depending on how it's configured. Unicast requests and broadcast messages are usually sent every 64 s to 1024 s, depending on how the client and server are set up 🦋
Okay so for unicast, the client builds the SNTP header, sends it off to the server, and then pulls the time of day out of the reply 🎀 To do that, every header field shown above gets set to 0 except the first octet. In that octet, LI is set to 0 (no warning) and Mode is set to 3 (client) 💖 The VN field has to match the software version of the NTP or SNTP server, but NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC-1119) and Version 1 (RFC-1059) messages, and NTP Version 2 servers will also accept Version 1 messages. Version 0 (RFC-959) messages are no longer supported, so 😭 no more of those. Since NTP servers of all three versions are still out there interoperating on the Internet today, it is recommended that VN be set to 1 ✨
In both unicast and broadcast modes, the server reply or broadcast message has all the fields described above, but in SNTP only the Transmit Timestamp has explicit meaning, and only if it's nonzero 🌸 Its integer part holds the server's time of day in the same format as the UDP/TIME Protocol [POS83]. The fraction part is usually valid too, but SNTP's accuracy might only justify using it down to a significant fraction of a second 🙈 If the Transmit Timestamp is 0, the message should be disregarded 💀
In broadcast mode, the client has no extra info to work out the propagation delay between server and client, because the Transmit Timestamp and Receive Timestamp fields mean nothing in this mode 😭 Even in unicast mode, most clients will probably just ignore the Originate Timestamp and Receive Timestamp fields anyway 💅 But in unicast mode there's a simple calculation that gives you the roundtrip delay d and local clock offset t relative to the server, usually to within a few tens of milliseconds ✨ Here's how it goes: the client sets the Originate Timestamp in the request to its local clock's time of day, converted to NTP timestamp format 🎀 When the reply arrives, the client works out a Destination Timestamp as its local clock's arrival time, also converted to NTP timestamp format 🫶 Here's the summary of the four timestamps:
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received at server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received at clientAnd the roundtrip delay d and local clock offset t are defined as:
d = (T4 - T1) - (T2 - T3)
t = ((T2 - T1) + (T3 - T4)) / 2.Here's a summary of the SNTP client operations 🔥 There are two recommended error checks shown in the table. In all NTP versions, if LI is 3, or Stratum isn't in the range 1-15, or Transmit Timestamp is 0, that means the server has never synchronized or hasn't synced to a valid timing source within the last 24 hours 👑 At the client's discretion, the remaining fields can be checked too. And if one or more of these fields looks invalid, whether to believe the transmit timestamp is up to the implementation 🧚
Field Name Request Reply
-------------------------------------------------------------
LI 0 leap indicator; if 3
(unsynchronized), disregard
message
VN 1 (see text) ignore
Mode 3 (client) ignore
Stratum 0 ignore
Poll 0 ignore
Precision 0 ignore
Root Delay 0 ignore
Root Dispersion 0 ignore
Reference Identifier 0 ignore
Reference Timestamp 0 ignore
Originate Timestamp 0 (see text) ignore (see text)
Receive Timestamp 0 ignore (see text)
Transmit Timestamp 0 time of day; if 0
(unsynchronized), disregard
message
Authenticator (not used) ignore6. SNTP Server Operations 🦋
Okay so an SNTP server working with an NTP or SNTP client is an RPC server with no persistent state either 💖 A SNTP server doesn't usually run the full set of NTP algorithms meant for redundant peers and diverse network paths, so it is recommended that a SNTP server only be run together with an external sync source, like a reliable radio clock 🎀 In that case the server always operates at stratum 1 👑
A server can run in unicast mode, broadcast mode, or both at once 🌈 In unicast mode, the server gets a request message, changes certain fields in the NTP or SNTP header, and sends the message back to the sender, possibly reusing the same message buffer as the request ✨ The server may or may not respond if it isn't synchronized to a correctly operating radio clock, but the preferred option is to respond, since that lets reachability be figured out regardless of sync state 🫶 In unicast mode, the VN and Poll fields of the request are copied intact into the reply. If the request's Mode is 3 (client), it's set to 4 (server) in the reply; otherwise it's set to 2 (symmetric passive) so it conforms to the NTP specification 💅
In broadcast mode, the server only sends messages if it's synchronized to a correctly operating reference clock 🔥 In this mode, VN is set to 3 (for the current SNTP version) and Mode is set to 5 (broadcast) 🧚 Poll is set to the server poll interval, in seconds, rounded to the nearest power of two 🌸 It is highly desirable that a server supporting broadcast mode also supports unicast mode 🙈 This is necessary so a potential broadcast client can work out the propagation delay using client/server messages before regular operation with only broadcast messages 💖
The remaining fields are set the same way in both unicast and broadcast modes 🦋 Assuming the server is synchronized to a radio clock or other primary reference source and operating correctly, Stratum is set to 1 (primary server) and LI is set to 0; if not, Stratum is set to 0 and LI is set to 3 💀 Precision is set to reflect the maximum reading error of the local clock. For all practical cases it's computed as the negative of the number of significant bits to the right of the decimal point in the NTP timestamp format 🎀 Root Delay and Root Dispersion are set to 0 for a primary server. Optionally, Root Dispersion can be set to a value matching the maximum expected error of the radio clock itself 🌈 Reference Identifier is set to designate the primary reference source, as shown in the table above ✨
The timestamp fields work like this 🫶 If the server is unsynchronized or just coming up, all timestamp fields are set to zero. If it is synchronized, Reference Timestamp is set to the time the last update came in from the radio clock or, if that's unavailable, to the time of day when the message is sent 👑 Receive Timestamp and Transmit Timestamp are set to the time of day when the message is sent. In unicast mode, Originate Timestamp is copied unchanged from the Transmit Timestamp of the request. It's important that this field gets copied intact, because an NTP client uses it to check for replays 😭 In broadcast mode, this field is set to the time of day when the message is sent. Here's the summary table:
Field Name Request Reply
----------------------------------------------------------
LI ignore 0 (normal), 3
(unsynchronized)
VN 1, 2 or 3 3 or copied from request
Mode 3 (see text) 2, 4 or 5 (see text)
Stratum ignore 1 server stratum
Poll ignore copied from request
Precision ignore server precision
Root Delay ignore 0
Root Dispersion ignore 0 (see text)
Reference Identifier ignore source identifier
Reference Timestamp ignore 0 or time of day
Originate Timestamp ignore 0 or time of day or copied
from Transmit Timestamp of
request
Receive Timestamp ignore 0 or time of day
Transmit Timestamp (see text) 0 or time of day
Authenticator ignore (not used)There's some latitude for most clients to forgive invalid timestamps, like when first coming up or when the primary reference source is down 💅 The most important sign of an unhealthy server is the LI field, where a value of 3 means unsynchronized 🚨 When that value shows up, clients SHOULD discard the server message, regardless of what the other fields say 😭
Heads up bestie: the original says "should discard" here, so I've kept it as "SHOULD" in caps to keep the exact same force 🫶
7. References 📚
[DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
RFC 1112, Stanford University, August 1989.
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis. RFC 1305, University of Delaware,
March 1992.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, USC/Information Sciences Institute, SRI, May 1983.Security Considerations 🔥
Security issues are not discussed in this memo. 💀
Author's Address 🎀
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
EMail: mills@udel.edu📦 where this page comes from
- ietf: rfc1769 1995-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms