[Git][NTPsec/ntpsec][master] 2 commits: text revision

[Matt Selsky]

Matt Selsky pushed to branch master at NTPsec / ntpsec


Commits:
74315ce7 by James Browning at 2019-12-10T03:38:35Z
text revision


- - - - -
830ab8bb by Richard Laager at 2019-12-10T03:38:35Z
Revise more text in packet.py

- - - - -


1 changed file:

- pylib/packet.py


Changes:

=====================================
pylib/packet.py
=====================================
@@ -56,7 +56,7 @@ the general structure of an NTP packet (Figure 8):
       |                          Key Identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
-      |                            dgst (128)                         |
+      |                           digest (128)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
@@ -66,7 +66,7 @@ Stratum and all following fields zeroed out to byte 47.
 
 How to interpret these fields:
 
-Mode is decoded as follows:
+The modes are as follows:
 
 +-------+--------------------------+
 | Value | Meaning                  |
@@ -82,10 +82,10 @@ Mode is decoded as follows:
 +-------+--------------------------+
 
 While the Stratum field has 8 bytes, only values 0-16 (low 5 bits)
-are legal. Value 16 means 'unsychronized' Value 17-255 are reserved.
+are legal. Value 16 means 'unsynchronized' Values 17-255 are reserved.
 
 LI (Leap Indicator), Version, Poll, and Precision are not described
-here; see RFC5905.
+here; see RFC 5905.
 
 t_1, the origin timestamp, is the time according to the client at
 which the request was sent.
@@ -96,7 +96,7 @@ which the request was received.
 t_3, the transmit timestamp, is the time according to the server at
 which the reply was sent.
 
-You also need t_4, the destination timestamp, is the time according to
+You also need t_4, the destination timestamp, which is the time according to
 the client at which the reply was received.  This is not in the reply packet,
 it's the packet receipt time collected by the client.
 
@@ -107,14 +107,14 @@ most recent reference-clock.
 
 Theta is the thing we want to estimate: the offset between the server
 clock and the client clock. The sign convention is that theta is
-positive iff the server is ahead of the client.
+positive if the server is ahead of the client.
 
 Theta is estimated by [(t_2-t_1)+(t_3-t_4)]/2. The accuracy of this
 estimate is predicated upon network latency being symmetrical.
 
 Delta is the network round trip time, i.e. (t_4-t_1)-(t_3-t_2). Here's
 how the terms work: (t_4-t_1) is the total time that the request was
-in flight, and (t_3-t_2) is time that the server spent processing it;
+in flight, and (t_3-t_2) is the time that the server spent processing it;
 when you subtract that out you're left with just network delays.
 
 Lambda nominally represents the maximum amount by which theta could be
@@ -143,7 +143,7 @@ If you look at the raw data, there are 3 unknowns:
    * clock offset
 but there are only two equations, so you can't solve it.
 
-NTP gets a 3rd equation by assuming the transit times are equal.  That lets
+NTP gets the 3rd equation by assuming the transit times are equal.  That lets
 it solve for the clock offset.
 
 If you assume that both clocks are accurate which is reasonable if you have
@@ -153,7 +153,7 @@ direction.
 The RFC 5905 diagram is slightly out of date in that the digest header assumes
 a 128-bit (16-octet) MD5 hash, but it is also possible for the field to be a
 128-bit AES_CMAC hash or 160-bit (20-octet) SHA-1 hash.  NTPsec will
-support any 128- or 160-bit MAC type in lincrypto.
+support any 128- or 160-bit MAC type in libcrypto.
 
 An extension field consists of a 16-bit network-order type field
 length, followed by a 16-bit network-order payload length in octets,
@@ -189,11 +189,11 @@ Here's what a Mode 6 packet looks like:
       |                          Key Identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
-      |                            dgst (128)                         |
+      |                           digest (128)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-In this case the fixed header is 24 bytes long.
+In this case, the fixed header is 24 bytes long.
 
 R = Response bit
 E = Error bit



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/d1795ae7f2f2b18540e8be3f256651a6b2dd078d...830ab8bb0fc45fe483ec2ebc72b74aaa98e18657

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/d1795ae7f2f2b18540e8be3f256651a6b2dd078d...830ab8bb0fc45fe483ec2ebc72b74aaa98e18657
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20191210/69f45cd5/attachment-0001.htm>