rfc9607v2.txt		rfc9607.txt
	skipping to change at line 176 ¶		skipping to change at line 176 ¶
	Because knowledge of the SCIP payload format is not needed to		Because knowledge of the SCIP payload format is not needed to
	transport SCIP signaling or media through middleboxes, SCIP-210		transport SCIP signaling or media through middleboxes, SCIP-210
	represents an informative reference. While older versions of the		represents an informative reference. While older versions of the
	SCIP-210 specification are publicly available, the authors strongly		SCIP-210 specification are publicly available, the authors strongly
	encourage network implementers to treat SCIP payloads as opaque		encourage network implementers to treat SCIP payloads as opaque
	octets. When handled correctly, such treatment does not require		octets. When handled correctly, such treatment does not require
	referring to SCIP-210, and any assumptions about the format of SCIP		referring to SCIP-210, and any assumptions about the format of SCIP
	messages defined in SCIP-210 are likely to lead to protocol		messages defined in SCIP-210 are likely to lead to protocol
	ossification and communication failures as the protocol evolves.		ossification and communication failures as the protocol evolves.
			| Note: The IETF has not conducted a security review of SCIP and
			| therefore has not verified the claims contained in this
			| document.
	2.1. Conventions		2.1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The best current practices for writing an RTP payload format		The best current practices for writing an RTP payload format
	specification, as per [RFC2736] and [RFC8088], were followed.		specification, as per [RFC2736] and [RFC8088], were followed.
	skipping to change at line 764 ¶		skipping to change at line 768 ¶
	DOI 10.17487/RFC9143, February 2022,		DOI 10.17487/RFC9143, February 2022,
	<https://www.rfc-editor.org/info/rfc9143>.		<https://www.rfc-editor.org/info/rfc9143>.
	[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol		[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
	Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,		Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
	December 2021, <https://www.rfc-editor.org/info/rfc9170>.		December 2021, <https://www.rfc-editor.org/info/rfc9170>.
	[RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)",		[RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)",
	<https://datatracker.ietf.org/wg/rmcat/about>.		<https://datatracker.ietf.org/wg/rmcat/about>.
	[SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210",		[SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210".
	<https://www.iad.gov/SecurePhone/index.cfm>.		Available by request via email to
			<ncia.cis3@ncia.nato.int>.
	Authors' Addresses		Authors' Addresses
	Daniel Hanson		Daniel Hanson
	General Dynamics Mission Systems, Inc.		General Dynamics Mission Systems, Inc.
	150 Rustcraft Road		150 Rustcraft Road
	Dedham, MA 02026		Dedham, MA 02026
	United States of America		United States of America
	Email: dan.hanson@gd-ms.com		Email: dan.hanson@gd-ms.com
End of changes. 2 change blocks.
	2 lines changed or deleted		7 lines changed or added
This html diff was produced by rfcdiff 1.48.