draft-mcquistin-augmented-ascii-diagrams-10.txt		draft-mcquistin-augmented-ascii-diagrams-11.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: 7 September 2022 C. S. Perkins		Expires: 10 March 2023 C. S. Perkins
	University of Glasgow		University of Glasgow
	6 March 2022		6 September 2022
	Describing Protocol Data Units with Augmented Packet Header Diagrams		Describing Protocol Data Units with Augmented Packet Header Diagrams
	draft-mcquistin-augmented-ascii-diagrams-10		draft-mcquistin-augmented-ascii-diagrams-11
	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 7 September 2022.		This Internet-Draft will expire on 10 March 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Limitations of Current Packet Format Diagrams . . . . . . 4		2.1. Limitations of Current Packet Format Diagrams . . . . . . 4
	2.2. Formal languages in standards documents . . . . . . . . . 7		2.2. Formal languages in standards documents . . . . . . . . . 7
	3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7		3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
	4. Augmented Packet Header Diagrams . . . . . . . . . . . . . . 10		4. Augmented Packet Header Diagrams . . . . . . . . . . . . . . 10
	4.1. PDUs with Fixed and Variable-Width Fields . . . . . . . . 10		4.1. PDUs with Fixed and Variable-Width Fields . . . . . . . . 10
	4.2. PDUs That Cross-Reference Previously Defined Fields . . . 13		4.2. PDUs That Cross-Reference Previously Defined Fields . . . 13
	4.3. PDUs with Non-Contiguous Fields . . . . . . . . . . . . . 16		4.3. PDUs with Non-Contiguous Fields . . . . . . . . . . . . . 16
	4.4. PDUs with Constraints on Field Values . . . . . . . . . . 17		4.4. PDUs with Constraints on Field Values . . . . . . . . . . 17
	4.5. PDUs with Constraints on Field Sizes . . . . . . . . . . 18		4.5. PDUs with Constraints on Field Sizes . . . . . . . . . . 18
	4.6. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 20		4.6. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 21
	4.7. Storing Data for Parsing . . . . . . . . . . . . . . . . 22		4.7. Storing Data for Parsing . . . . . . . . . . . . . . . . 22
	4.8. Connecting Structures with Functions . . . . . . . . . . 22		4.8. Connecting Structures with Functions . . . . . . . . . . 23
	4.9. Specifying Enumerated Types . . . . . . . . . . . . . . . 23		4.9. Specifying Enumerated Types . . . . . . . . . . . . . . . 24
	4.10. Specifying Protocol Data Units . . . . . . . . . . . . . 25		4.10. Specifying Protocol Data Units . . . . . . . . . . . . . 25
	4.11. Importing PDU Definitions from Other Documents . . . . . 25		4.11. Importing PDU Definitions from Other Documents . . . . . 26
	5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25		5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	9. Informative References . . . . . . . . . . . . . . . . . . . 26		9. Informative References . . . . . . . . . . . . . . . . . . . 27
	Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 29		Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 29
	A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 29		A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 29
	A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 29		A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 29
	Appendix B. Tooling & source code . . . . . . . . . . . . . . . 29		Appendix B. Tooling & source code . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
	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 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	with the packet header diagrams and structured text format described		with the packet header diagrams and structured text format described
	by example. Examples that do not form part of the protocol		by example. Examples that do not form part of the protocol
	description language are marked by a colon at the beginning of each		description language are marked by a colon at the beginning of each
	line; this prevents them from being parsed by the accompanying		line; this prevents them from being parsed by the accompanying
	tooling.		tooling.
	This draft describes early work. As consensus builds around the		This draft describes early work. As consensus builds around the
	particular syntax of the format described, a formal ABNF		particular syntax of the format described, a formal ABNF
	specification (Appendix A) will be provided.		specification (Appendix A) will be provided.
	Example specifications of a number of IETF protocols described using		Code that parses documents written using this format, and that
	the Augmented Packet Header Diagram format are available. These		automatically generates parser code for the described protocols, is
	documents describe UDP [draft-mcquistin-augmented-udp-example], TCP		described in Appendix B.
	[draft-mcquistin-augmented-tcp-example], and QUIC
	[draft-mcquistin-quic-augmented-diagrams]. Code that parses those
	documents and automatically generates parser code for the described
	protocols is described in Appendix B.
	2. Background		2. Background
	This section begins by considering how packet header diagrams are		This section begins by considering how packet header diagrams are
	used in existing documents. This exposes the limitations that the		used in existing documents. This exposes the limitations that the
	current usage has in terms of machine-readability, guiding the design		current usage has in terms of machine-readability, guiding the design
	of the format that this document proposes.		of the format that this document proposes.
	While this document focuses on the machine-readability of packet		While this document focuses on the machine-readability of packet
	format diagrams, this section also discusses the use of other		format diagrams, this section also discusses the use of other
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 20 ¶
	begins with the text "where:".		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.11).		language defined in Section 4.11).
	Each field is defined by a structured text definition and a prose		Each field is defined by a structured text definition and a prose
	description. The structured text definition comprises the field name		description. The structured text definition comprises the field name
	and an optional short name in parenthesis. These are followed by a		and an optional short name in parenthesis. These are followed by a
	colon, the field length, an optional presence expression (described		colon, the field length, an optional presence expression (described
	in Section 4.2), and a terminating period. Text following the		in Section 4.2), and, optionally, a terminating period. Text
	terminating period is not parsed, and this space can be used for		following the terminating period is not parsed, and this space can be
	optional notes or comments. Field names cannot be the same as a		used for optional notes or comments. Field names cannot be the same
	previously defined PDU name, and must be unique within a given		as a previously defined PDU name, and must be unique within a given
	structure definition. The structured text definition is given either		structure definition. The structured text definition is given either
	in a <dt> tag (if using a <dl>) or as the "hangText" (if using a		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		hanging <list>) of a <t> element. The field's prose description is
	given in the following <dd> element or within the same <t> element.		given in the following <dd> element or within the same <t> element.
	Prose descriptions may include structured text (e.g., as defined in		Prose descriptions may include structured text (e.g., as defined in
	Section 4.7).		Section 4.7).
	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:
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	A PDU may contain fields that have a size that is specified in terms		A PDU may contain fields that have a size that is specified in terms
	of the value of another field. So far, our constraint syntax can be		of the value of another field. So far, our constraint syntax can be
	used to specify the length of fields in known units (of bits, bytes,		used to specify the length of fields in known units (of bits, bytes,
	or other structures). If the units are of variable-width, then it		or other structures). If the units are of variable-width, then it
	may not be possible to specify the length of the sequence. However,		may not be possible to specify the length of the sequence. However,
	it is still necessary to be able to constraint the overall width of		it is still necessary to be able to constraint the overall width of
	the field. To support this, our constraint syntax includes a "size"		the field. To support this, our constraint syntax includes a "size"
	function that evaluates to the width, in bits, of the given named		function that evaluates to the width, in bits, of the given named
	field.		field.
	This syntax is illustrated using the TCP Header format		This syntax is illustrated using the TCP Header format [RFC9293]. A
	[draft-ietf-tcpm-rfc793bis]. A TCP Header is formatted as follows:		TCP 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Destination Port |		| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgment Number |		| Acknowledgment Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 19, line 47 ¶		skipping to change at page 19, line 47 ¶
	Acknowledgment Number: 32 bits. This is a fixed-width field as		Acknowledgment Number: 32 bits. This is a fixed-width field as
	previously described.		previously described.
	Data Offset (DOffset): 4 bits; DOffset >= 5. This is a fixed-width		Data Offset (DOffset): 4 bits; DOffset >= 5. This is a fixed-width
	field, with a value constraint, as previously described.		field, with a value constraint, as previously described.
	Reserved (Rsrvd): 4 bits; Rsrvd == 0. This is a fixed-width field,		Reserved (Rsrvd): 4 bits; Rsrvd == 0. This is a fixed-width field,
	with a value constraint, as previously described.		with a value constraint, as previously described.
	CWR: 1 bit. This is a fixed-width field as previously described.		Control bits: Optionally, field description lists can be nested. If
			the XML element (either a <dd> or a <t>) containing the
			description of a field contains an XML list (either <dl> or
			hanging <list>) as its last element, then this nested list will be
			parsed for fields, and the outer description will be ignored. In
			this example, "Control bits" describes the group of 8 single bit
			fields that are described in the list that follows; it is these
			single bit fields that will form part of the structure.
	ECE: 1 bit. This is a fixed-width field as previously described.		CWR: 1 bit. This is a fixed-width field as previously described.
	URG: 1 bit. This is a fixed-width field as previously described.		ECE: 1 bit. This is a fixed-width field as previously described.
	ACK: 1 bit. This is a fixed-width field as previously described.		URG: 1 bit. This is a fixed-width field as previously described.
	PSH: 1 bit. This is a fixed-width field as previously described.		ACK: 1 bit. This is a fixed-width field as previously described.
	RST: 1 bit. This is a fixed-width field as previously described.		PSH: 1 bit. This is a fixed-width field as previously described.
	SYN: 1 bit. This is a fixed-width field, with a value constraint, as		RST: 1 bit. This is a fixed-width field as previously described.
	previously described.
	FIN: 1 bit; (FIN == 0) || (SYN == 0). This is a fixed-width field,		SYN: 1 bit. This is a fixed-width field, with a value constraint,
	with a value constraint, as previously described.		as previously described.
			FIN: 1 bit; (FIN == 0) || (SYN == 0). This is a fixed-width
			field, with a value constraint, as previously described.
	Window Size: 16 bits. This is a fixed-width field as previously		Window Size: 16 bits. This is a fixed-width field as previously
	described.		described.
	Checksum: 16 bits. This is a fixed-width field as previously		Checksum: 16 bits. This is a fixed-width field as previously
	described.		described.
	Urgent Pointer: 16 bits. This is a fixed-width field as previously		Urgent Pointer: 16 bits. This is a fixed-width field as previously
	described.		described.
	skipping to change at page 24, line 6 ¶		skipping to change at page 24, line 24 ¶
	The alternative structures that comprise an enumerated type are		The alternative structures that comprise an enumerated type are
	identified using the exact phrase "The <enumerated type name> is one		identified using the exact phrase "The <enumerated type name> is one
	of: <list of structure names>" where the list of structure names is a		of: <list of structure names>" where the list of structure names is a
	comma separated list (with the last element, if there is more than		comma separated list (with the last element, if there is more than
	one element, preceded by 'or'), each optionally preceded by "a" or		one element, preceded by 'or'), each optionally preceded by "a" or
	"an". The structure names must be defined within the document or a		"an". The structure names must be defined within the document or a
	linked document. Optionally, this phrase can include a note or		linked document. Optionally, this phrase can include a note or
	comment, delimited by commas, immediately following the enumerated		comment, delimited by commas, immediately following the enumerated
	type name. That is, "The <enumerated type name>, with an optional		type name. That is, "The <enumerated type name>, with an optional
	comment, is one of: <list of structure names>" can be used to define		comment, is one of: <list of structure names>" can be used to define
	an enumerated type.		an enumerated type. In both cases, the colon is optional; for
			example, "The <enumerated type name> is one of <list of structure
			names>" is valid.
	Where an enumerated type has only two variants, an alternative phrase		Where an enumerated type has only two variants, an alternative phrase
	can be used: "The <enumerated type name> is either a <variant 1 name>		can be used: "The <enumerated type name> is either a <variant 1 name>
	or <variant 2 name>". The names of the variants must be defined		or <variant 2 name>". The names of the variants must be defined
	within the document or a linked document. An optional note or		within the document or a linked document. An optional note or
	comment can be included with this alternative phrasing: "The		comment can be included with this alternative phrasing: "The
	<enumerated type name>, with an optional comment, is either a		<enumerated type name>, with an optional comment, is either a
	<variant 1 name> or <variant 2 name>" can be used.		<variant 1 name> or <variant 2 name>" can be used.
	An EOL Option is formatted as follows:		An EOL Option is formatted as follows:
	skipping to change at page 25, line 18 ¶		skipping to change at page 25, line 37 ¶
	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
	document to identify those structures that are PDUs.		document to identify those structures that are PDUs.
	The PDUs that comprise a protocol are identified using the exact		The PDUs that comprise a protocol are identified using the exact
	phrase "This document describes the <protocol name> protocol. The		phrase "This document describes the <protocol name> protocol. The
	<protocol name> protocol uses <list of PDU names>" where the list of		<protocol name> protocol uses <list of PDU names>" where the list of
	PDU names is a comma separated list (with the last element, if there		PDU names is a comma separated list (with the last element, if there
	is more than one element, preceded by 'and'), each optionally		is more than one element, preceded by 'and'), each optionally
	preceded by "a" or "an". The PDU names must be structure names		preceded by "a" or "an". As a short-form, the variation "This
	defined in the document or a linked document. The PDU names are		document describes the <protocol name>, which uses <list of PDU
	pluralised in the list. A document must contain exactly one instance		names>" can be used as an alternative. The PDU names must be
	of this phrase.		structure names defined in the document or a linked document. The
			PDU names are pluralised in the list. A document must contain
			exactly one instance of this phrase.
	This document describes the Example protocol. The Example protocol		This document describes the Example protocol. The Example protocol
	uses Long Headers, STUN Message Types, IPv4 Headers, RTP Data		uses Long Headers, STUN Message Types, IPv4 Headers, RTP Data
	Packets, and TCP Headers.		Packets, and TCP Headers.
	4.11. Importing PDU Definitions from Other Documents		4.11. Importing PDU Definitions from Other Documents
	Protocols are often specified across multiple documents, either		Protocols are often specified across multiple documents, either
	because the specification of a protocol's data units has changed over		because the specification of a protocol's data units has changed over
	time, or because of explicit extension points contained in the		time, or because of explicit extension points contained in the
	skipping to change at page 26, line 41 ¶		skipping to change at page 27, line 21 ¶
	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		Wesley Eddy provided valuable feedback on the description format
	through adopting it in [draft-ietf-tcpm-rfc793bis].		through adopting it in [RFC9293].
	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
	skipping to change at page 28, line 25 ¶		skipping to change at page 29, line 5 ¶
	[LANGSEC] LANGSEC, "LANGSEC: Language-theoretic Security",		[LANGSEC] LANGSEC, "LANGSEC: Language-theoretic Security",
	<http://langsec.org>.		<http://langsec.org>.
	[SASSAMAN] Sassaman, L., Patterson, M. L., Bratus, S., and A.		[SASSAMAN] Sassaman, L., Patterson, M. L., Bratus, S., and A.
	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]		[RFC9293] Eddy, W., "Transmission Control Protocol", RFC 9293,
	McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,		August 2022, <https://www.rfc-editor.org/info/rfc9293>.
	"Describing UDP with Augmented Packet Header Diagrams",
	Work in Progress, Internet-Draft, draft-mcquistin-
	augmented-udp-example-02, 25 October 2021,
	<http://www.ietf.org/internet-drafts/draft-mcquistin-
	augmented-udp-02.txt>.
	[draft-mcquistin-augmented-tcp-example]
	McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
	"Describing TCP with Augmented Packet Header Diagrams",
	Work in Progress, Internet-Draft, draft-mcquistin-
	augmented-tcp-example-02, 25 October 2021,
	<http://www.ietf.org/internet-drafts/draft-mcquistin-
	augmented-tcp-example-02.txt>.
	[draft-mcquistin-quic-augmented-diagrams]
	McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
	"Describing QUIC's Protocol Data Units with Augmented
	Packet Header Diagrams", Work in Progress, Internet-Draft,
	draft-mcquistin-quic-augmented-diagrams-04, 25 October
	2021, <http://www.ietf.org/internet-drafts/draft-
	mcquistin-quic-augmented-diagrams-05.txt>.
	[draft-ietf-tcpm-rfc793bis]
	Eddy, W., "Transmission Control Protocol (TCP)
	Specification", Work in Progress, Internet-Draft, draft-
	ietf-tcpm-rfc793bis-27, 22 February 2022,
	<http://www.ietf.org/internet-drafts/draft-ietf-tcpm-
	rfc793bis-27.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 30, line 4 ¶		skipping to change at page 30, line 10 ¶
	Appendix B. Tooling & source code		Appendix B. Tooling & source code
	The source for this draft is available from https://github.com/		The source for this draft is available from https://github.com/
	glasgow-ipl/draft-mcquistin-augmented-ascii-diagrams.		glasgow-ipl/draft-mcquistin-augmented-ascii-diagrams.
	The source code for tooling that can be used to parse this document		The source code for tooling that can be used to parse this document
	is available from https://github.com/glasgow-ipl/ips-protodesc-code.		is available from https://github.com/glasgow-ipl/ips-protodesc-code.
	This tooling supports the automatic generation of Rust parser code		This tooling supports the automatic generation of Rust parser code
	from protocol descriptions written in the Augmented Packet Header		from protocol descriptions written in the Augmented Packet Header
	Diagram format. It also provides test harnesses that demonstrate		Diagram format. It also provides test harnesses that demonstrate
	that example descriptions of UDP		that the description of TCP [RFC9293] written in this format can be
	[draft-mcquistin-augmented-udp-example] and TCP		used to generate parser code.
	[draft-mcquistin-augmented-udp-example] function as expected.
	Authors' Addresses		Authors' Addresses
	Stephen McQuistin		Stephen McQuistin
	University of Glasgow		University of Glasgow
	School of Computing Science		School of Computing Science
	Glasgow		Glasgow
	G12 8QQ		G12 8QQ
	United Kingdom		United Kingdom
	Email: sm@smcquistin.uk		Email: sm@smcquistin.uk
End of changes. 24 change blocks.
	73 lines changed or deleted		53 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/