rfc9592v2.txt		rfc9592.txt
	Internet Engineering Task Force (IETF) N. ten Oever		Internet Engineering Task Force (IETF) N. ten Oever
	Request for Comments: 9592 University of Amsterdam		Request for Comments: 9592 University of Amsterdam
	Obsoletes: 6722 G. Wood		Obsoletes: 6722 G. Wood
	Category: Informational IETF Administration LLC		Category: Informational IETF Administration LLC
	ISSN: 2070-1721 May 2024		ISSN: 2070-1721 June 2024
	Retiring the Tao of the IETF		Retiring the Tao of the IETF
	Abstract		Abstract
	This document retires and obsoletes the Tao of the IETF as an IETF-		This document retires and obsoletes the Tao of the IETF as an IETF-
	maintained document. This document also obsoletes RFC 6722, which		maintained document. This document also obsoletes RFC 6722, which
	describes the publication process of the Tao. Furthermore, this		describes the publication process of the Tao. Furthermore, this
	document describes the rationale for the retirement of the Tao. For		document describes the rationale for the retirement of the Tao. For
	archival purposes, the last version of the Tao is included in the		archival purposes, the last version of the Tao is included in the
	skipping to change at line 1698 ¶		skipping to change at line 1698 ¶
	into great detail on a topic that is very often misunderstood, even		into great detail on a topic that is very often misunderstood, even
	by seasoned IETF participants: different types of RFCs go through		by seasoned IETF participants: different types of RFCs go through
	different processes and have different rankings.		different processes and have different rankings.
	6.2 Common Issues		6.2 Common Issues
	There are two major issues that often come up while preparing I-Ds:		There are two major issues that often come up while preparing I-Ds:
	copyright and patents.		copyright and patents.
	We discussed copyright above, but expand on it here. When the IETF		We discussed copyright above, but expand on it here. When the IETF
	adopts a Internet-Draft, it is required that the _boilerplate_, the		adopts an Internet-Draft, it is required that the _boilerplate_, the
	common text that appears in every draft, has a notice that says the		common text that appears in every draft, has a notice that says the
	IETF, _and the document authors_ own the copyright. This means that		IETF, _and the document authors_ own the copyright. This means that
	while the IETF can do what it wants with the document, within		while the IETF can do what it wants with the document, within
	limitations so can you. You cannot, for example, claim this is an		limitations so can you. You cannot, for example, claim this is an
	IETF standard, nor use the IETF trademarks.		IETF standard, nor use the IETF trademarks.
	Incidentally, the change control on Internet standards doesn't end		Incidentally, the change control on Internet standards doesn't end
	when the RFC is published. Things can be changed later for a number		when the RFC is published. Things can be changed later for a number
	of reasons, such as to solve a newly-discovered problem or address		of reasons, such as to solve a newly-discovered problem or address
	new use-cases. These later changes are also under the control of the		new use-cases. These later changes are also under the control of the
	skipping to change at line 1829 ¶		skipping to change at line 1829 ¶
	the standard. A non-normative reference (sometimes called an		the standard. A non-normative reference (sometimes called an
	_informative reference_) is one that is helpful to an implementor but		_informative reference_) is one that is helpful to an implementor but
	not strictly needed to implement it.		not strictly needed to implement it.
	An IETF standard may make a normative reference to any other		An IETF standard may make a normative reference to any other
	standards-track RFC that is at the same standards level or higher, or		standards-track RFC that is at the same standards level or higher, or
	to any "open standard" that has been developed outside the IETF. The		to any "open standard" that has been developed outside the IETF. The
	"same level or higher" rule means that before a standard can move		"same level or higher" rule means that before a standard can move
	from Proposed to Internet Standard, all of the RFCs that appear as a		from Proposed to Internet Standard, all of the RFCs that appear as a
	normative reference must also be an Internet Standard. This rule		normative reference must also be an Internet Standard. This rule
	gives implementors assurance that everything in a Internet standard		gives implementors assurance that everything in an Internet standard
	is quite stable, even the things referenced outside the standard.		is quite stable, even the things referenced outside the standard.
	This rule, and its exceptions, is described in BCP 97		This rule, and its exceptions, is described in BCP 97
	(https://www.rfc-editor.org/info/bcp97).		(https://www.rfc-editor.org/info/bcp97).
	There is no hard-and-fast rule about what is an "open standard", but		There is no hard-and-fast rule about what is an "open standard", but
	generally this means a stable standard that was made by a generally-		generally this means a stable standard that was made by a generally-
	recognized SDO, and that anyone can get a copy of, although not		recognized SDO, and that anyone can get a copy of, although not
	necessarily for free. If the external standard changes, you have to		necessarily for free. If the external standard changes, you have to
	reference the particular instantiation of that standard in your		reference the particular instantiation of that standard in your
	specification, as with a designation of the date of the standard.		specification, as with a designation of the date of the standard.
End of changes. 3 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.