Timetravel 2024-08-06 snapshot

[sthagen]

Next warp 2024-08-06 ← 2024-08-01 (branch name was misleading)

[sthagen]

The corresponding diff from the freshly available download as markdown route is even more to the point (because the vendor platform has stable image identifiers and a line length limit of 512 🙈 it seems):

❯ diff -u mqtt-sn-v2.0-wd-snapshot-20240801T194400Z.md mqtt-sn-v2.0-wd-snapshot-20240806T182800Z.md
--- mqtt-sn-v2.0-wd-snapshot-20240801T194400Z.md	2024-08-01 21:45:50
+++ mqtt-sn-v2.0-wd-snapshot-20240806T182800Z.md	2024-08-06 20:30:03
@@ -170,7 +170,7 @@

 [3.1.4.9 Connect Will Flags (optional, only with Will flag set)	37](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set))

-[3.1.4.10 Will Topic Short or Will Topic Length (optional, only with Will flag set)	37](\#3.1.4.10-will-topic-short-or-will-topic-length-(optional,-only-with-will-flag-set))
+[3.1.4.10 Will Topic Short or Will Topic Length (optional, only with Will flag set)	37](\#3.1.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set))

 [3.1.4.11 Will Payload Length (optional, only with Will flag set)	37](\#3.1.4.11-will-payload-length-(optional,-only-with-will-flag-set))

\ No newline at end of file
@@ -680,7 +680,7 @@

 A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions.

-Also known as a **Gateway**.
+Also known as a **Gateway** or **GW**.

 A Server:

\ No newline at end of file
@@ -829,16 +829,16 @@

 1. In addition to Topic Alias and long Topic Names MQTT-SN allows predefined and short two-byte Topic Names.

-1. If the network supports Multicast, Gateway discovery can be implemented, otherwise the Gateway addresses must be configured in the nodes.
+2. If the network supports Multicast, Gateway discovery can be implemented, otherwise the Gateway addresses must be configured in the nodes.

-1. Support for sleeping clients allows battery operated devices to enter a low power mode. In this state, Application Messages for the Client are buffered by the Gateway and delivered when the client wakes.
+3. Support for sleeping clients allows battery operated devices to enter a low power mode. In this state, Application Messages for the Client are buffered by the Gateway and delivered when the client wakes.

-1. A new Quality of Service level (WITHOUT SESSION) is introduced in MQTT-SN, allowing devices to publish without a session having been established.
-
-1. MQTT-SN has fewer requirements on the underlying transport and it can use connectionless network transports such as User Datagram Protocol (UDP).
+4. A new Quality of Service level (WITHOUT SESSION) is introduced in MQTT-SN, allowing devices to publish without a session having been established.

-1. MQTT-SN introduces the PROTECTION packet for packet-based security based on symmetric-key cryptography.
+5. MQTT-SN has fewer requirements on the underlying transport and it can use connectionless network transports such as User Datagram Protocol (UDP).

+6. MQTT-SN introduces the PROTECTION packet for packet-based security based on symmetric-key cryptography.
+
 ## **1.7 Data representation** {#1.7-data-representation}

 ### **1.7.1 Bits (Byte)** {#1.7.1-bits-(byte)}
\ No newline at end of file
@@ -1106,7 +1106,7 @@
 | 133 | 0x85 | Client identifier not valid | CONNACK | The Client Identifier is a valid string but is not allowed by the Server. |
 | 134 | 0x86 | Bad user name or password | CONNACK | The Server does not accept the User Name or Password specified by the Client  |
 | 135 | 0x87 | Not authorized | CONNACK, PUBACK, PUBREC, REGACK, SUBACK, UNSUBACK, DISCONNECT (server only) | The request is not authorized. |
-| 136 | 0x88 | Server unavailable | CONNACK | The MQTT Server is not available. |
+| 136 | 0x88 | Server unavailable | CONNACK | The MQTT-SN Server is not available or, in case of Transparent gateway, the MQTT server is not available. |
 | 137 | 0x89 | Server busy | CONNACK, DISCONNECT (server only) | The Server is busy and cannot continue processing requests from this Client. |
 | 138 | 0x8A | Banned | CONNACK | This Client has been banned by administrative action. Contact the server administrator. |
 | 139 | 0x8B | Server shutting down | DISCONNECT (server only) | The Server is shutting down.  |
\ No newline at end of file
@@ -1115,7 +1115,7 @@
 | 142 | 0x8E | Session taken over | DISCONNECT (server only) | Another Connection using the same ClientID has connected causing this Connection to be closed. |
 | 143 | 0x8F | Topic filter invalid | SUBACK, UNSUBACK, DISCONNECT (server only) | The Topic Filter is correctly formed, but is not accepted by this Server. |
 | 144 | 0x90 | Topic name invalid | CONNACK, PUBACK, PUBREC, DISCONNECT (server only) | The Topic Name is correctly formed, but is not accepted by this Client or Server. |
-| 145 | 0x91 | Packet identifier in use | PUBACK, PUBREC, SUBACK, UNSUBACK | The specified Packet Identifier is already in use. |
+| 145 | 0x91 | Packet identifier in use | PUBACK, PUBREC, SUBACK, UNSUBACK, PINGRESP | The specified Packet Identifier is already in use. |
 | 146 | 0x92 | Packet identifier not found | PUBREL, PUBCOMP | The Packet Identifier is not known. This is not an error during recovery, but at other times indicates a mismatch between the Session State on the Client and Server.  |
 | 147 | 0x93 | Receive maximum exceeded | DISCONNECT | The Client or Server has received more than Receive Maximum publication for which it has not sent PUBACK or PUBCOMP.  |
 | 148 | 0x94 | Topic alias invalid | DISCONNECT (server only) | The Client or Server has received a PUBLISH packet containing a Topic Alias which is greater than the Maximum Topic Alias it sent in the CONNECT or CONNACK packet.  (Transparent gateway only) |
\ No newline at end of file
@@ -1136,19 +1136,19 @@
 | 230 | 0xE6 | Only PROTECTION packet supported (Note 1\) | Any packet except PROTECTION and Forwarder Encapsulation | Specific to MQTT-SN |
 | 231 | 0xE7 | Protection scheme invalid | DISCONNECT | Specific to MQTT-SN |
 | 232 | 0xE8 | Unknown Sender Id | DISCONNECT | Specific to MQTT-SN |
-| 240 | 0xF0 | Unknown Topic Alias | PUBACK, SUBACK | Specific to MQTT-SN |
+| 240 | 0xF0 | Unknown Topic Alias | PUBACK, SUBACK, UNSUBACK, REGACK | Specific to MQTT-SN |
 | 241 | 0xF1 | Congestion | SUBACK, REGACK, CONNACK, PUBACK | Specific to MQTT-SN |
 | 242 | 0xF2 | Protection packet not supported | DISCONNECT | Specific to MQTT-SN |
 | 243 | 0xF3 | Forwarder Encapsulation not supported | DISCONNECT | Specific to MQTT-SN |
 | 244 | 0xF4 | Unknown topic alias | SUBACK, UNSUBACK, PUBACK, REGACK | Specific to MQTT-SN |
-| 245-255 | 0xF5-0xFF | Reserved for MQTT-SN |  | Specific to MQTT-SN |
+| 2445-255 | 0xF5-0xFF | Reserved for MQTT-SN |  | Specific to MQTT-SN |

 Table 9: Reason Code Values

 Note(s):

 1. It is used by a receiver to indicate that it expected a packet to be protected and it wasn't.
-1. The MQTT-SN dedicated range of reason codes is from 0xE6 (230) to 0xFF(255).
+2. The MQTT-SN dedicated range of reason codes is from 0xE6 (230) to 0xFF(255).

 ### **2.3.4 Topic Data** {#2.3.4-topic-data}

\ No newline at end of file
@@ -1366,7 +1366,7 @@

 If a Client does not receive a PINGRESP packet within a *Tretry* amount of time after it has sent a PINGREQ, it SHOULD retry the transmission according to [section 4.24](\#4.4.1-unacknowledged-packets) up to the maximum number of attempts. If a PINGRESP is still not received it MUST close the Session to the Gateway by way of a DISCONNECT, with the understanding that the GW may no longer be reachable.

-A Keep Alive must have a value greater than 0\. It is considered a protocol error If a Keep Alive value of 0 is set.
+A Keep Alive must have a value greater than 0\. It is considered a protocol error iIf a Keep Alive value of 0 or below is set.

 **Informative comment**
 The Gateway may have other reasons to disconnect the Client, for instance because it is shutting down. Setting Keep Alive does not guarantee that the Client will remain connected.
\ No newline at end of file
@@ -1417,7 +1417,7 @@

 A Client Identifier can be between 0 \- 65,521 bytes. We advise for practicality, ClientID’s are restricted to a reasonable size (less than 243 bytes to fit within a small CONNECT packet).

-When the clientID is present (greater than 0 bytes), the Gateway MUST allow values which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”.
+When the CclientID is present (greater than 0 bytes), the Gateway MUST allow values which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”.

 The Gateway may choose to allow more than 23 bytes.

\ No newline at end of file
@@ -1447,7 +1447,7 @@

 The Server SHOULD publish Will Messages promptly after the Virtual Connection is deleted or the Session ends, whichever occurs first. In the case of a Server shutdown or failure, the Server MAY defer publication of Will Messages until a subsequent restart. If this happens, there might be a delay between the time the Server experienced failure and when the Will Message is published.

-#### **3.1.4.10 Will Topic Short or Will Topic Length (optional, only with *Will* flag set)** {#3.1.4.10-will-topic-short-or-will-topic-length-(optional,-only-with-will-flag-set)}
+#### **3.1.4.10 Will Topic DataShort or Will Topic Length (optional, only with *Will* flag set)** {#3.1.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set)}

 In the case of Will Topic Type being b11 this field will refer to the length of data assigned to the “Will Full Topic Name”, in all other cases, this will be the value used as the Will topic alias or Will short topic name.

\ No newline at end of file
@@ -1463,33 +1463,33 @@

 #### **3.1.4.13 Authentication Method Length (optional, only with *Auth* flag set)** {#3.1.4.13-authentication-method-length-(optional,-only-with-auth-flag-set)}

-Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.

 #### **3.1.4.14 Authentication Method (optional, only with *Auth* flag set)** {#3.1.4.14-authentication-method-(optional,-only-with-auth-flag-set)}

-A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.

 #### **3.1.4.15 Authentication Data Length (optional, only with *Auth* flag set)** {#3.1.4.15-authentication-data-length-(optional,-only-with-auth-flag-set)}

-Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.

 #### **3.1.4.16 Authentication Data (optional, only with *Auth* flag set)** {#3.1.4.16-authentication-data-(optional,-only-with-auth-flag-set)}

-Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.

 #### **3.1.4.17 CONNECT Actions** {#3.1.4.17-connect-actions}

 Note that a Server MAY support multiple protocols on the same network endpoint. If the Server determines that the protocol is MQTT-SN 2.0 then it validates the connection attempt as follows.

 1. The Server MUST validate that the CONNECT packet matches the format described in [section 3.1.4](\#3.1.4-connect---connection-request) and MUST NOT create a Virtual Connection for this CONNECT if it does not match. \[MQTT-SN-3.1.4.17-1\] The Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in [section 4.12](\#4.12-handling-errors).
-1. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.1.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.1.5](\#3.1.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).
+2. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.1.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.1.5](\#3.1.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).

 If validation is successful, the Server performs the following steps.

 1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in [section 4.12](\#4.12-handling-errors) and MUST delete the Virtual Connection of the existing Client \[MQTT-SN-3.1.4.17-3\]. If the existing Client has a Will Message, that Will Message is published as described in section 3.1.2.5.
-1. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.1.4.17-4\].
-1. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.1.4.17-5\].
-1. Start Application Message delivery and Keep Alive monitoring.
+2. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.1.4.17-4\].
+3. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.1.4.17-5\].
+4. Start Application Message delivery and Keep Alive monitoring.

    **Informative comment**

\ No newline at end of file
@@ -1632,7 +1632,7 @@

 #### **3.1.7.2 Packet Identifier** {#3.1.7.2-packet-identifier}

-Used to identify the corresponding CONNECT, AUTH or CONNACK packet. It should ideally be populated with a random integer value when sent from Client to Server. When sent from Server to Client, it MUST contain the packet identifier of the CONNECT or AUTH packet being responded to.
+Used to identify the corresponding CONNECT or, AUTH or CONNACK packet. It should ideally be populated with a random integer value when sent from Client to Server. When sent from Server to Client, it MUST contain the packet identifier of the CONNECT or AUTH packet being responded to.

 #### **3.1.6.2 Reason Code** {#3.1.6.2-reason-code}

\ No newline at end of file
@@ -1902,10 +1902,12 @@
 #### **3.1.12.6 Data** {#3.1.12.6-data}

 The *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
+
+In the case of Topic Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.

 #### **3.1.12.7 PUBLISH Actions** {#3.1.12.7-publish-actions}

-The receiver of a PUBLISH Packet MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.1.12.7-1\].
+The receiver of a PUBLISH pPacket MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.1.12.7-1\].

  Table 3‑3 Expected PUBLISH packet response

\ No newline at end of file
@@ -2564,14 +2566,14 @@
 **Note(s):**

 1. Reference [https://www.rfc-editor.org/rfc/rfc2104](https://www.rfc-editor.org/rfc/rfc2104)
-1. Reference [https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf)
-1. Reference [https://www.rfc-editor.org/rfc/rfc4493](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4493\&data=05%7C01%7Cdavide.lenzarini%40u-blox.com%7C4c9137c28d464ec349b908db260113dd%7C80c4ffa675114bba9f03e5872a660c9b%7C0%7C0%7C638145558306431211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C\&sdata=xugq2R3JL90RCv%2BzdnQqW7rtztg1MF6xtBAYnqa1K8s%3D\&reserved=0) and [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) and https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Standards-and-Guidelines/documents/examples/AES\_CMAC.pdf
-1. Reference [https://www.rfc-editor.org/rfc/rfc3610](https://www.rfc-editor.org/rfc/rfc3610) and security considerations on [https://www.rfc-editor.org/rfc/rfc8152\#section-10.2.1](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8152%23section-10.2.1\&data=05%7C01%7Cdavide.lenzarini%40u-blox.com%7C4c9137c28d464ec349b908db260113dd%7C80c4ffa675114bba9f03e5872a660c9b%7C0%7C0%7C638145558306431211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C\&sdata=DTxkXC3J%2B8Wj2l7qn6U5cFUExdZVFXPv2Ss3M2%2B1VLY%3D\&reserved=0)
-1. AES CCM requires a 13 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.2 and the nonce is obtained by performing SHA256, truncated to the leftmost 104 bits, of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
-1. Reference https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.1.1
-1. AES GCM requires a 12 bytes IV as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.1 and the IV is obtained by performing SHA256, truncated to the leftmost 96 bits, of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
-1. Reference: https://www.rfc-editor.org/rfc/rfc7539 and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.3.1
-1. ChaCha20/Poly1305 requires a 12 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.3 obtained by performing SHA256 truncated to 96 bit of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
+2. Reference [https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf)
+3. Reference [https://www.rfc-editor.org/rfc/rfc4493](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4493\&data=05%7C01%7Cdavide.lenzarini%40u-blox.com%7C4c9137c28d464ec349b908db260113dd%7C80c4ffa675114bba9f03e5872a660c9b%7C0%7C0%7C638145558306431211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C\&sdata=xugq2R3JL90RCv%2BzdnQqW7rtztg1MF6xtBAYnqa1K8s%3D\&reserved=0) and [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) and https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Standards-and-Guidelines/documents/examples/AES\_CMAC.pdf
+4. Reference [https://www.rfc-editor.org/rfc/rfc3610](https://www.rfc-editor.org/rfc/rfc3610) and security considerations on [https://www.rfc-editor.org/rfc/rfc8152\#section-10.2.1](https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8152%23section-10.2.1\&data=05%7C01%7Cdavide.lenzarini%40u-blox.com%7C4c9137c28d464ec349b908db260113dd%7C80c4ffa675114bba9f03e5872a660c9b%7C0%7C0%7C638145558306431211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C\&sdata=DTxkXC3J%2B8Wj2l7qn6U5cFUExdZVFXPv2Ss3M2%2B1VLY%3D\&reserved=0)
+5. AES CCM requires a 13 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.2 and the nonce is obtained by performing SHA256, truncated to the leftmost 104 bits, of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
+6. Reference https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.1.1
+7. AES GCM requires a 12 bytes IV as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.1 and the IV is obtained by performing SHA256, truncated to the leftmost 96 bits, of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
+8. Reference: https://www.rfc-editor.org/rfc/rfc7539 and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.3.1
+9. ChaCha20/Poly1305 requires a 12 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.3 obtained by performing SHA256 truncated to 96 bit of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)

 #### **3.1.26.5 Sender Identifier** {#3.1.26.5-sender-identifier}

\ No newline at end of file
@@ -2847,7 +2849,7 @@
 There are two situations when packets that require acknowledgement are resent by the sender:

 1. when a Virtual Connection is deleted before the acknowledgement is received by the requester (and clean start is false)
-1. when no acknowledgment is received by the by the requester within a configured timeout period during the existence of a Virtual Connection
+2. when no acknowledgment is received by the by the requester within a configured timeout period during the existence of a Virtual Connection

 These two situations are described in the following two sections.

\ No newline at end of file
@@ -3756,11 +3758,11 @@
 An exponential backoff algorithm retries requests exponentially, increasing the waiting time between retries up to a maximum backoff time. For example:

 1. Initial packet sent.
-1. If the operation fails, wait 1000 \+ (random number) milliseconds (ran) and retry the operation.
-1. If the operation fails, wait 2000 \+ (random number) milliseconds (ran) and retry the operation.
-1. If the operation fails, wait 4000 \+ (random number) milliseconds (ran) and retry the operation.
-1. Continued, up to a maximum backoff *MBACKOFF*.
-1. Continue waiting and retrying up to some maximum number of retries, but do not increase the wait period between retries.
+2. If the operation fails, wait 1000 \+ (random number) milliseconds (ran) and retry the operation.
+3. If the operation fails, wait 2000 \+ (random number) milliseconds (ran) and retry the operation.
+4. If the operation fails, wait 4000 \+ (random number) milliseconds (ran) and retry the operation.
+5. Continued, up to a maximum backoff *MBACKOFF*.
+6. Continue waiting and retrying up to some maximum number of retries, but do not increase the wait period between retries.

 The wait time is min(((2^n \* sf) \+ ran), max) with n incremented by 1 for each iteration (or operation) and the scaling factor (sf) being set to some reasonable value (suggested 1000 as in the example above).

\ No newline at end of file