RFC Errata
Found 5 records.
Status: Verified (5)
RFC 5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", February 2009
Note: This RFC has been updated by RFC 7631, RFC 8245
Source of RFC: manet (rtg)
Errata ID: 3496
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-02-25
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28
Section Appendix A says:
o The <pkt-seq-num> field, if present, contains a sequence number
that is incremented by 1 for each packet generated by a node. The
sequence number after 65535 is 0. In other words, the sequence
number "wraps" in the usual way.
It should say:
o The <pkt-seq-num> field, if present, contains a sequence number
that SHOULD be maintained for each participating interface and
incremented by 1 for each packet generated by a node for that
interface. The sequence number after 65535 is 0. In other words,
the sequence number "wraps" in the usual way.
Notes:
Packet sequence number should be per interface, not per node. Uses that recognise missing packet sequence numbers only work in the corrected (intended) case.
Errata ID: 1790
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yannick Lacharité
Date Reported: 2009-06-02
Verifier Name: Adrian Farrel
Date Verified: 2011-08-04
Section Appendix E says:
[...]
The packet contains a single message with length 54 octets.
^
[...]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
^
It should say:
[...]
The packet contains a single message with length 55 octets.
^
[...]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1| Orig Addr |
^
Notes:
Correction to the message length, which is 55 instead of 54.
Errata ID: 3497
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-02-25
Verifier Name: Adrian Farrel
Date Verified: 2013-02-28
Section Appendix D.6 says:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
It should say:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|1|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Notes:
Corrects example TLV to have correct <tlv-flags> bits.
Errata ID: 4003
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2014-05-29
Verifier Name: Adrian Farrel
Date Verified: 2014-05-29
Section Appendix B says:
o <msg-hop-limit> field, if present, contains the number of hops on
which the packet is allowed to travel before being discarded by a
MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly
circulating in a MANET. When forwarding a message, a MANET router
should decrease the <msg-hop-limit> by 1, and the message should
be discarded when <msg-hop-limit> reaches 0.
o <msg-hop-count> field, if present, contains the number of hops on
which the packet has traveled across the MANET. The <msg-hop-
count> is set to 0 by the message originator and is used to
prevent messages from endlessly circulating in a MANET. When
forwarding a message, a MANET router should increase <msg-hop-
count> by 1 and should discard the message when <msg-hop-count>
reaches 255.
It should say:
o <msg-hop-limit> field, if present, contains the number of hops on
which the message is allowed to travel before being discarded by a
MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly
circulating in a MANET. When forwarding a message, a MANET router
should decrease the <msg-hop-limit> by 1, and the message should
be discarded when <msg-hop-limit> reaches 0.
o <msg-hop-count> field, if present, contains the number of hops on
which the message has traveled across the MANET. The <msg-hop-
count> is set to 0 by the message originator and is used to
prevent messages from endlessly circulating in a MANET. When
forwarding a message, a MANET router should increase <msg-hop-
count> by 1 and should discard the message when <msg-hop-count>
reaches 255.
Notes:
Two changes of "packet" to "message". Message is consistent with the normative Section 5.2 that defines these fields (which may appear in each message, so are not uniquely defined for a packet), the text introducing these bullet points, and the remainder of these paragraphs.
(Note that the original and corrected text has had indentation reduced by one space.)
Errata ID: 4178
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ronald in 't Velt
Date Reported: 2014-11-13
Verifier Name: Adrian Farrel
Date Verified: 2014-11-18
Section 6.5.1 says:
When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
It should say:
When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines an Address Block TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
Notes:
'Message TLV Type' should read 'Address Block TLV Type'. This is likely a 'Copy-Paste' error from section 6.4.1, which stipulates a similar requirement for Message TLV Type Extension Registry creation.