Fix typos in docs

doc/control-plane.rst

@@ -106,7 +106,7 @@ An originated PCB sent to a child AS initiates the intra-ISD beacon creating an
 Propagation of PCBs
 -------------------
 
-PCBs are propgated at regular intervals at each AS.
+PCBs are propagated at regular intervals at each AS.
 When PCBs are received, they are not propagated immediately, but put into temporary storage
 until the next propagation event.
 The selection and propagation of PCBs differs between the inter-ISD and intra-ISD beacon schemes.
@@ -160,7 +160,7 @@ or :file-ref:`proto/control_plane/v1/seg.proto` for the raw protocol definitions
    :end-at: }
 
 .. literalinclude:: /../proto/control_plane/v1/seg.proto
-   :caption: Hop field protobuf message definition. This is a part of the ``HopEntry``, refererred to
+   :caption: Hop field protobuf message definition. This is a part of the ``HopEntry``, referred to
              in the ``ASEntrySignedBody`` definition above.
    :language: proto
    :start-at: message HopField {
@@ -188,7 +188,7 @@ lookup process.
 As mentioned previously, a non-core AS typically receives several PCBs representing path segments to
 the core ASes of the ISD the AS belongs to.
 Out of these PCBs, the non-core AS selects those down-path segments through which it wants to be
-reached, based on AS-specific selection critera.
+reached, based on AS-specific selection criteria.
 The next step is to register the selected down-segments with the control service of the
 core AS that originated the PCB.
 

doc/glossary.rst

@@ -53,7 +53,7 @@ Glossary
       An endpoint can be an end host, but it applies slightly more generically to any node which is
       the source or destination of SCION traffic, e.g. to a gateway.
 
-      The terms "endpoint" and "end host" are used mostly interchangably.
+      The terms "endpoint" and "end host" are used mostly interchangeably.
       End host is preferred where the focus is (physical or virtual) machines and the software
       running on them, and endpoint is used otherwise.
 

doc/hidden-paths.rst

@@ -149,7 +149,7 @@ Below is an example registration configuration.
 
 Segments constructed via interfaces not listed in the registration policy will not
 be registered at all. This default prevents the scenario where an AS that wants to stay
-hidden adds an new interface, and announces paths to itself without realizing.
+hidden adds a new interface, and announces paths to itself without realizing.
 
 Example complete configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

doc/protocols/authenticator-option.rst

@@ -76,7 +76,7 @@ Timestamp / Sequence Number:
   .. note::
     In other words, the duplicate suppression would happen within the
     acceptance windows considering identical values for the Authenticator field, which is
-    computed based on packet contents, such as the Timestamp (used to derived the *AbsTime*)
+    computed based on packet contents, such as the Timestamp (used to derive the *AbsTime*)
     and the upper layer payload
     (see the section :ref:`Authenticated Data<authenticated-data>`).
 

doc/protocols/extension-header.rst

@@ -8,7 +8,7 @@ This document contains the specification of the SCION extension headers. There
 are two extension headers defined, the *Hop-by-Hop (HBH) Options Header* and the
 *End-to-End (E2E) Options Header*. A SCION packet can have at most **one** of
 each. If both headers are present, the HBH options **MUST** come before the E2E
-options. The option header support a variable number of *type-length-value
+options. The option header supports a variable number of *type-length-value
 (TLV)* encoded options.
 
 .. _hop-by-hop-options:

doc/protocols/scion-header.rst

@@ -173,7 +173,7 @@ current and preceding info fields.
 This construction allows for up to three info fields, which is the maximum for a
 SCION path. Should there ever be a path type with more than three segments, this
 would require a new path type to be introduced (which would also allow for a
-backwards-compatible upgrade). The advantage of this construction is that all
+backward-compatible upgrade). The advantage of this construction is that all
 the offsets can be calculated and validated purely from the path meta header,
 which greatly simplifies processing logic.
 
@@ -203,7 +203,7 @@ C
 RSV
     Unused and reserved for future use.
 SegID
-    SegID is a updatable field that is required for the MAC-chaining mechanism.
+    SegID is an updatable field that is required for the MAC-chaining mechanism.
 Timestamp
     Timestamp created by the initiator of the corresponding beacon. The
     timestamp is expressed in Unix time, and is encoded as an unsigned integer