draft-mcquistin-augmented-ascii-diagrams-07.txt   draft-mcquistin-augmented-ascii-diagrams-08.txt 
Network Working Group S. McQuistin Network Working Group S. McQuistin
Internet-Draft V. Band Internet-Draft V. Band
Intended status: Experimental D. Jacob Intended status: Experimental D. Jacob
Expires: 6 May 2021 C. S. Perkins Expires: 6 November 2021 C. S. Perkins
University of Glasgow University of Glasgow
2 November 2020 5 May 2021
Describing Protocol Data Units with Augmented Packet Header Diagrams Describing Protocol Data Units with Augmented Packet Header Diagrams
draft-mcquistin-augmented-ascii-diagrams-07 draft-mcquistin-augmented-ascii-diagrams-08
Abstract Abstract
This document describes a machine-readable format for specifying the This document describes a machine-readable format for specifying the
syntax of protocol data units within a protocol specification. This syntax of protocol data units within a protocol specification. This
format is comprised of a consistently formatted packet header format is comprised of a consistently formatted packet header
diagram, followed by structured explanatory text. It is designed to diagram, followed by structured explanatory text. It is designed to
maintain human readability while enabling support for automated maintain human readability while enabling support for automated
parser generation from the specification document. This document is parser generation from the specification document. This document is
itself an example of how the format can be used. itself an example of how the format can be used.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2021. This Internet-Draft will expire on 6 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.5. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 18 4.5. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 18
4.6. Storing Data for Parsing . . . . . . . . . . . . . . . . 19 4.6. Storing Data for Parsing . . . . . . . . . . . . . . . . 19
4.7. Connecting Structures with Functions . . . . . . . . . . 20 4.7. Connecting Structures with Functions . . . . . . . . . . 20
4.8. Specifying Enumerated Types . . . . . . . . . . . . . . . 21 4.8. Specifying Enumerated Types . . . . . . . . . . . . . . . 21
4.9. Specifying Protocol Data Units . . . . . . . . . . . . . 22 4.9. Specifying Protocol Data Units . . . . . . . . . . . . . 22
4.10. Importing PDU Definitions from Other Documents . . . . . 22 4.10. Importing PDU Definitions from Other Documents . . . . . 22
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. Informative References . . . . . . . . . . . . . . . . . . . 23 9. Informative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 26 Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 26
A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 26 A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 26
A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 26 A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 26
Appendix B. Tooling & source code . . . . . . . . . . . . . . . 26 Appendix B. Tooling & source code . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Packet header diagrams have become a widely used format for Packet header diagrams have become a widely used format for
describing the syntax of binary protocols. In otherwise largely describing the syntax of binary protocols. In otherwise largely
skipping to change at page 11, line 6 skipping to change at page 10, line 49
a field is either derived from the value of some previous field, or a field is either derived from the value of some previous field, or
is unspecified and inferred from the total size of the packet and the is unspecified and inferred from the total size of the packet and the
size of the other fields. size of the other fields.
To ensure that there is no ambiguity, a PDU description can contain To ensure that there is no ambiguity, a PDU description can contain
only one field whose length is unspecified. The length of a single only one field whose length is unspecified. The length of a single
field, where all other fields are of known (but perhaps variable) field, where all other fields are of known (but perhaps variable)
length, can be inferred from the total size of the containing PDU. length, can be inferred from the total size of the containing PDU.
A PDU description is introduced by the exact phrase "A/An _______ is A PDU description is introduced by the exact phrase "A/An _______ is
formatted as follows:" at the end of a paragraph. This is followed formatted as follows" within a paragraph. This is followed by the
by the PDU description itself, as a packet diagram within an PDU description itself, as a packet diagram within an <artwork>
<artwork> element in the XML representation, starting with a header element (itself optionally within a <figure> element) in the XML
line to show the bit width of the diagram. The description of the representation, starting with a header line to show the bit width of
fields follows the diagram, as an XML <dl> list, after a paragraph the diagram. The description of the fields follows the diagram, as
containing the text "where:". an XML list (either <dl> or hanging <list>), after a paragraph that
begins with the text "where:".
PDU names must be unique, both within a document, and across all PDU names must be unique, both within a document, and across all
documents that are linked together (i.e., using the structured documents that are linked together (i.e., using the structured
language defined in Section 4.10). language defined in Section 4.10).
Each field of the description starts with a <dt> tag comprising the Each field is defined by a structured text definition and a prose
field name and an optional short name in parenthesis. These are description. The structured text definition comprises the field name
followed by a colon, the field length, an optional presence and an optional short name in parenthesis. These are followed by a
expression (described in Section 4.2), and a terminating period. The colon, the field length, an optional presence expression (described
following <dd> tag contains a prose description of the field. Field in Section 4.2), and a terminating period. Field names cannot be the
names cannot be the same as a previously defined PDU name, and must same as a previously defined PDU name, and must be unique within a
be unique within a given structure definition. given structure definition. The structured text definition is given
either in a <dt> tag (if using a <dl>) or as the "hangText" (if using
a hanging <list>) of a <t> element. The field's prose description is
given in the following <dd> element or within the same <t> element.
Prose descriptions may include structured text (e.g., as defined in
Section 4.6).
For example, this can be illustrated using the IPv4 Header Format For example, this can be illustrated using the IPv4 Header Format
[RFC791]. An IPv4 Header is formatted as follows: [RFC791]. An IPv4 Header is formatted as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL | DSCP |ECN| Total Length | |Version| IHL | DSCP |ECN| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset | | Identification |Flags| Fragment Offset |
skipping to change at page 15, line 30 skipping to change at page 15, line 30
refers to the length of the PDU, while the field name refers to refers to the length of the PDU, while the field name refers to
the value of the field. This is possible because field names the value of the field. This is possible because field names
cannot be the same as previously defined PDU names. cannot be the same as previously defined PDU names.
Header Extension: 32 bits; present only when X == 1. This is a field Header Extension: 32 bits; present only when X == 1. This is a field
whose presence is predicated on an expression given using the whose presence is predicated on an expression given using the
constraint expression grammar described earlier. Optional fields constraint expression grammar described earlier. Optional fields
can be of any previously defined format (e.g., fixed- or variable- can be of any previously defined format (e.g., fixed- or variable-
width). Optional fields are indicated by the presence of "; width). Optional fields are indicated by the presence of ";
present only when [expr]." at the end of the definition term present only when [expr]." at the end of the definition term
(i.e., the text contained within the <dt> tag). (i.e., the text contained within the <dt> tag or "hangText"
attribute).
[Note that this example deviates from the format as described in [Note that this example deviates from the format as described in
[RFC3550]. As specified in that document, the Header Extension [RFC3550]. As specified in that document, the Header Extension
would be a cross-referenced structure. This is not shown here for would be a cross-referenced structure. This is not shown here for
brevity.] brevity.]
Payload. The length of the Payload is not specified, and hence needs Payload. The length of the Payload is not specified, and hence needs
to be inferred from the total length of the packet and the lengths to be inferred from the total length of the packet and the lengths
of the known fields. There can only be one field of unspecified of the known fields. There can only be one field of unspecified
size in a PDU. size in a PDU. Fields where the length is not specified may also
denote this with the phrase "variable length" in place of the
length definition.
Padding: PC bytes; present only when (P == 1) && (PC > 0). This is a Padding: PC bytes; present only when (P == 1) && (PC > 0). This is a
variable size field, with size dependent on a later field in the variable size field, with size dependent on a later field in the
packet. Fields can only depend on the value of a later field if packet. Fields can only depend on the value of a later field if
they follow a field with unspecified size. they follow a field with unspecified size.
Padding Count (PC): 1 byte; present only when P == 1. This is a Padding Count (PC): 1 byte; present only when P == 1. This is a
fixed-width field, as previously discussed. fixed-width field, as previously discussed.
4.3. PDUs with Non-Contiguous Fields 4.3. PDUs with Non-Contiguous Fields
skipping to change at page 16, line 26 skipping to change at page 16, line 26
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|M|M|M|M|C|M|M|M|C|M|M|M|M| |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
|B|A|9|8|7|1|6|5|4|0|3|2|1|0| |B|A|9|8|7|1|6|5|4|0|3|2|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Method (M): 12 bits. This field is comprised of multiple sub-fields Method (M): 12 bits (split field). This field is comprised of
(M0 through MB) as shown in the diagram. That these sub-fields multiple sub-fields (M0 through MB) as shown in the diagram. That
should be concatenated, after parsing, into a single field is these sub-fields should be concatenated, after parsing, into a
indicated by their being labelled using the 'M' short field name single field is indicated by their being labelled using the 'M'
followed by a single hexadecimal digit, with the least significant short field name followed by a single hexadecimal digit, with the
bit labelled with 0, and subsequent bits labelled in sequence. least significant bit labelled with 0, and subsequent bits
labelled in sequence.
Class (C): 2 bits. This field follows the same format as M described Class (C): 2 bits (split field). This field follows the same format
above. as M described above.
4.4. PDUs with Constraints on Field Values 4.4. PDUs with Constraints on Field Values
A PDU may be defined not only by the layout and type of its fields, A PDU may be defined not only by the layout and type of its fields,
but also by the value of those fields. For example, field values may but also by the value of those fields. For example, field values may
be constrained to be of a known exact value or to be within a range. be constrained to be of a known exact value or to be within a range.
More generally, our format enables a boolean expression to be More generally, our format enables a boolean expression to be
attached to a field, which must be true for the PDU to be parsed attached to a field, which must be true for the PDU to be parsed
successfully. successfully.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (SCID) ... | Source Connection ID (SCID) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Header Form (HF): 1 bit; HF == 1. This is a fixed-width field, Header Form (HF): 1 bit; HF == 1. This is a fixed-width field,
constrained to be a of an known, exact value. At most one field constrained to be a of an known, exact value. At most one field
value constraint may be given, and if provided, it must be given value constraint may be given, and if provided, it must be given
as a boolean expression, separated by a semi-colon in the field as a boolean expression, separated by a semi-colon in the field
definition name (i.e., the text contained within the <dt> tag). definition name (i.e., the text contained within the <dt> tag or
If present, a value constraint must follow the name, short name, "hangText" attribute). If present, a value constraint must follow
and length of the field, but appear before any presence the name, short name, and length of the field, but appear before
constraint, if applicable. The order of the field must be the any presence constraint, if applicable. The order of the field
same in both the diagram and description list. must be the same in both the diagram and description list.
Fixed Bit (FB): 1 bit; FB == 1. This is a fixed-width field, with a Fixed Bit (FB): 1 bit; FB == 1. This is a fixed-width field, with a
value constraint, as previously described. value constraint, as previously described.
Long Packet Type (T): 2 bits. This is a fixed-width field as Long Packet Type (T): 2 bits. This is a fixed-width field as
previously described. previously described.
Reserved Bits (R): 2 bits. This is a fixed-width field as previously Reserved Bits (R): 2 bits. This is a fixed-width field as previously
described. described.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Long Header (LH): 1 Long Header; LH.T == 3. This field is a Long Header (LH): 1 Long Header; LH.T == 3. This field is a
previously defined sub-structure. Its constraints can access previously defined sub-structure. Its constraints can access
fields in that sub-structure. In this example, the T field of the fields in that sub-structure. In this example, the T field of the
Long Header must be equal to 3. Long Header must be equal to 3.
Retry Token This is a variable-length field as previously defined. Retry Token. This is a variable-length field as previously defined.
Retry Integrity Tag: 128 bits. This is a fixed-width field as Retry Integrity Tag: 128 bits. This is a fixed-width field as
previously defined. previously defined.
As shown, the Long Header packet sub-structure is included. The As shown, the Long Header packet sub-structure is included. The
Retry Packet enforces a new value constraint on the Long Packet Type Retry Packet enforces a new value constraint on the Long Packet Type
(T) field. (T) field.
4.6. Storing Data for Parsing 4.6. Storing Data for Parsing
The parsing process may require data from previously parsed The parsing process may require data from previously parsed
structures. This means that data needs to be stored persistently structures. This means that data needs to be stored persistently
throughout the process. This data needs to be identified. throughout the process. This data needs to be identified.
That the value of a particular field be stored upon parsing is That the value of a particular field be stored upon parsing is
indicated by the exact phrase "On receipt, the value of <field name> indicated by the exact phrase "On receipt, the value of <field name>
is stored as <stored name>." being present at the end of the is stored as <stored name>." being present at the end of the
description of a field (i.e., at the end of the <dd> element.) description of a field (i.e., at the end of the <dd> or <t> element.)
An Initial Packet is formatted as follows: An Initial Packet is formatted as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
: Long Header : : Long Header :
: | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 37 skipping to change at page 21, line 37
A PING Frame is formatted as follows: A PING Frame is formatted as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Frame Type (FT): 1 Variable-Length Integer Encoding; FT.T == 1. Fram Frame Type (FT): 1 Variable Length Integer Encoding; FT.T == 1. Fram
e type, set to 1 for PING frames. e type, set to 1 for PING frames.
A HANDSHAKE_DONE Frame is formatted as follows: A HANDSHAKE_DONE Frame is formatted as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 30 | | 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Frame Type (FT): 1 Variable-Length Integer Encoding; FT.T == 30. Fra Frame Type (FT): 1 Variable Length Integer Encoding; FT.T == 30. Fra
me type, set to 30 for HANDSHAKE_DONE frames. me type, set to 30 for HANDSHAKE_DONE frames.
A Frame is either a PING Frame or a HANDSHAKE_DONE Frame. A Frame is either a PING Frame or a HANDSHAKE_DONE Frame.
4.9. Specifying Protocol Data Units 4.9. Specifying Protocol Data Units
A document will set out different structures that are not, on their A document will set out different structures that are not, on their
own, protocol data units. To capture the parsing or serialisation of own, protocol data units. To capture the parsing or serialisation of
a protocol, it is necessary to be able to identify or construct those a protocol, it is necessary to be able to identify or construct those
packets that are valid PDUs. As a result, it is necessary for the packets that are valid PDUs. As a result, it is necessary for the
skipping to change at page 23, line 44 skipping to change at page 23, line 44
community explores the security implications of programming language community explores the security implications of programming language
design; the principles developed in that community should guide the design; the principles developed in that community should guide the
development of protocol description languages. development of protocol description languages.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Marc Petit-Huguenin for extensive The authors would like to thank Marc Petit-Huguenin for extensive
feedback on the draft, including work on formalising the constraint feedback on the draft, including work on formalising the constraint
syntax as given in Appendix A.1. syntax as given in Appendix A.1.
Wesley Eddy provided valuable feedback on the description format
through adopting it in [draft-ietf-tcpm-rfc793bis].
The authors would like to thank David Southgate for preparing a The authors would like to thank David Southgate for preparing a
prototype implementation of some of the ideas described here. prototype implementation of some of the ideas described here.
This work has received funding from the UK Engineering and Physical This work has received funding from the UK Engineering and Physical
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
9. Informative References 9. Informative References
[RFC8357] Deering, S. and R. Hinden, "Generalized UDP Source Port [RFC8357] Deering, S. and R. Hinden, "Generalized UDP Source Port
for DHCP Relay", RFC 8357, March 2018, for DHCP Relay", RFC 8357, March 2018,
skipping to change at page 25, line 29 skipping to change at page 25, line 33
Shubina, "The Halting Problems of Network Stack Shubina, "The Halting Problems of Network Stack
Insecurity", ;login: -- December 2011, Volume 36, Number Insecurity", ;login: -- December 2011, Volume 36, Number
6, <https://www.usenix.org/publications/login/december- 6, <https://www.usenix.org/publications/login/december-
2011-volume-36-number-6/halting-problems-network-stack- 2011-volume-36-number-6/halting-problems-network-stack-
insecurity>. insecurity>.
[draft-mcquistin-augmented-udp-example] [draft-mcquistin-augmented-udp-example]
McQuistin, S., Band, V., Jacob, D., and C. S. Perkins, McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
"Describing UDP with Augmented Packet Header Diagrams", "Describing UDP with Augmented Packet Header Diagrams",
Work in Progress, Internet-Draft, draft-mcquistin- Work in Progress, Internet-Draft, draft-mcquistin-
augmented-udp-example-00, 2 November 2020, augmented-udp-example-01, 5 May 2021,
<http://www.ietf.org/internet-drafts/draft-mcquistin- <http://www.ietf.org/internet-drafts/draft-mcquistin-
augmented-udp-00.txt>. augmented-udp-01.txt>.
[draft-mcquistin-augmented-tcp-example] [draft-mcquistin-augmented-tcp-example]
McQuistin, S., Band, V., Jacob, D., and C. S. Perkins, McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
"Describing TCP with Augmented Packet Header Diagrams", "Describing TCP with Augmented Packet Header Diagrams",
Work in Progress, Internet-Draft, draft-mcquistin- Work in Progress, Internet-Draft, draft-mcquistin-
augmented-udp-example-00, 2 November 2020, augmented-tcp-example-01, 5 May 2021,
<http://www.ietf.org/internet-drafts/draft-mcquistin- <http://www.ietf.org/internet-drafts/draft-mcquistin-
augmented-tcp-example-00.txt>. augmented-tcp-example-01.txt>.
[draft-mcquistin-quic-augmented-diagrams] [draft-mcquistin-quic-augmented-diagrams]
McQuistin, S., Band, V., Jacob, D., and C. S. Perkins, McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
"Describing QUIC's Protocol Data Units with Augmented "Describing QUIC's Protocol Data Units with Augmented
Packet Header Diagrams", Work in Progress, Internet-Draft, Packet Header Diagrams", Work in Progress, Internet-Draft,
draft-mcquistin-quic-augmented-diagrams-03, 2 November draft-mcquistin-quic-augmented-diagrams-04, 5 May 2021,
2020, <http://www.ietf.org/internet-drafts/draft- <http://www.ietf.org/internet-drafts/draft-mcquistin-quic-
mcquistin-quic-augmented-diagrams-03.txt>. augmented-diagrams-04.txt>.
[draft-ietf-tcpm-rfc793bis]
Eddy, W., "Transmission Control Protocol (TCP)
Specification", Work in Progress, Internet-Draft, draft-
ietf-tcpm-rfc793bis-21, 3 May 2021, <http://www.ietf.org/
internet-drafts/draft-ietf-tcpm-rfc793bis-21.txt>.
Appendix A. ABNF specification Appendix A. ABNF specification
A.1. Constraint Expressions A.1. Constraint Expressions
constant = %x31-39 *(%x30-39) ; natural numbers without leading 0s constant = %x31-39 *(%x30-39) ; natural numbers without leading 0s
short-name = ALPHA *(ALPHA / DIGIT / "-" / "_") short-name = ALPHA *(ALPHA / DIGIT / "-" / "_")
name = short-name *(" " short-name) name = short-name *(" " short-name)
sp = [" "] ; optional space in expression sp = [" "] ; optional space in expression
bool-expr = "(" sp bool-expr sp ")" / bool-expr = "(" sp bool-expr sp ")" /
skipping to change at page 26, line 26 skipping to change at page 26, line 32
bool-expr sp "?" sp expr sp ":" sp expr / bool-expr sp "?" sp expr sp ":" sp expr /
expr sp cmp-op sp expr expr sp cmp-op sp expr
bool-op = "&&" / "||" bool-op = "&&" / "||"
cmp-op = "==" / "!=" / "<" / "<=" / ">" / ">=" cmp-op = "==" / "!=" / "<" / "<=" / ">" / ">="
expr = "(" sp expr sp ")" / expr = "(" sp expr sp ")" /
expr sp op sp expr / expr sp op sp expr /
bool-expr "?" expr ":" expr / bool-expr "?" expr ":" expr /
name / short-name "." short-name / name / short-name "." short-name /
constant constant
op = "+" / "-" / "*" / "/" / "%" / "^" op = "+" / "-" / "*" / "/" / "%" / "^"
length = expr sp unit / "[" sp name sp "]" length = expr sp unit / "[" sp name sp "]" / "variable length"
unit = %s"bit" / %s"bits" / %s"byte" / %s"bytes" / name unit = %s"bit" / %s"bits" / %s"byte" / %s"bytes" / name
A.2. Augmented packet diagrams A.2. Augmented packet diagrams
Future revisions of this draft will include an ABNF specification for Future revisions of this draft will include an ABNF specification for
the augmented packet diagram format described in Section 4. Such a the augmented packet diagram format described in Section 4. Such a
specification is omitted from this draft given that the format is specification is omitted from this draft given that the format is
likely to change as its syntax is developed. Given the visual nature likely to change as its syntax is developed. Given the visual nature
of the format, it is more appropriate for discussion to focus on the of the format, it is more appropriate for discussion to focus on the
examples given in Section 4. examples given in Section 4.
 End of changes. 24 change blocks. 
46 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/