From 2c6d25310734955c17d4c379e37b5dee652ce854 Mon Sep 17 00:00:00 2001 From: edoardottt Date: Thu, 12 Oct 2023 11:14:55 +0200 Subject: [PATCH] Fix typos in docs --- doc/control-plane.rst | 6 +++--- doc/glossary.rst | 2 +- doc/hidden-paths.rst | 2 +- doc/protocols/authenticator-option.rst | 2 +- doc/protocols/extension-header.rst | 2 +- doc/protocols/scion-header.rst | 4 ++-- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/control-plane.rst b/doc/control-plane.rst index eca9ce0720..d6beefd388 100644 --- a/doc/control-plane.rst +++ b/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. diff --git a/doc/glossary.rst b/doc/glossary.rst index 0083dcdbc4..68810d69ab 100644 --- a/doc/glossary.rst +++ b/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. diff --git a/doc/hidden-paths.rst b/doc/hidden-paths.rst index 4a24fd1aa4..79f9fcd959 100644 --- a/doc/hidden-paths.rst +++ b/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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/doc/protocols/authenticator-option.rst b/doc/protocols/authenticator-option.rst index 0770696036..93ad1ce3a3 100644 --- a/doc/protocols/authenticator-option.rst +++ b/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`). diff --git a/doc/protocols/extension-header.rst b/doc/protocols/extension-header.rst index 23e1447e44..a93ce7559c 100644 --- a/doc/protocols/extension-header.rst +++ b/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: diff --git a/doc/protocols/scion-header.rst b/doc/protocols/scion-header.rst index db71176cc9..c69093f96b 100644 --- a/doc/protocols/scion-header.rst +++ b/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