This IESG Statement deals with the proposed status for IETF documents reserving values, numbers, addresses, etc. for example purposes. In this statement we use the term 'resources' for these values, numbers, addresses, etc. As a general practice the IESG recommends that setting aside of resources for example purposes be made at the time the registries for these resources are created. In these situations, the assignments are part of documents that define the registries and the respective documents can have different statuses such as standards track, informational, or experimental. However in many cases the need for examples shows up later, and as a result a number of RFCs in the IETF stream have been issued with the principal purpose of reserving resources for documentation or example purposes, and preventing these values from being used in operational deployments and create undesired or unexpected effects on the Internet. It is assumed that such resources will be used in examples in RFCs, books, documentation, and the like. Currently there is no established and agreed practice of what proposed status the RFCs written for this purpose will take. Looking at a few examples of such documents one can see that RFCs with different statuses were approved in time by the IESG and published: RFC 2606 - Reserved Top Level DNS Names - BCP RFC 3849 - IPv6 Address Prefix Reserved for Documentation - Informational RFC 4735 - Example Media Types for Use in Documentation - Proposed Standard RFC 5398 - Autonomous System (AS) Number Reservation for Documentation Use - Informational The IESG recommends that in the future the proposed status for IETF documents with the exclusive or principal scope of reserving resources for example purposes should be BCP, with the exception of a couple of cases detailed below. The rationale of this recommendation is that BCP seems to be the appropriate status for such documents that standardize practices and recommend ways to make reservations of resources for example purposes, and the level of community deliberations associated with BCPs including IETF Last Call seems to be the right one. The alternative of standards-track documents is not justified, as documents that define resources for examples cannot be progressed through the maturity ladder as required for such documents. The second alternative of informational documents seems to be also inadequate, as informational documents do not represent any Internet community consensus or recommendations. The recommendation does not apply in the following cases: - If an existing specification requires a different document status for the respective type of resources. From this perspective using Proposed Standard for RFC 4735 was a justified choice, because as per RFC 4288 Section 8, all type names MUST be defined by a standards-track RFC. - If the respective resources belong to a space administered by IANA using a First Come First Served policy an Informational RFC status is sufficient. This recommendation takes effect from the date of publication of this IESG Statement and does not impact RFCs published until this date. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
