IESG Statement about the proposed status for IETF documents reserving resources for example purposes

IESG Secretary <iesg-secretary@ietf.org> Tue, 20 January 2009 18:30 UTC

Return-Path: <ietf-announce-bounces@ietf.org>
X-Original-To: ietf-announce-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA2D28C120; Tue, 20 Jan 2009 10:30:02 -0800 (PST)
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 2A05D3A6895; Tue, 20 Jan 2009 10:30:00 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: ietf-announce@ietf.org
Subject: IESG Statement about the proposed status for IETF documents reserving resources for example purposes
Mime-Version: 1.0
Message-Id: <20090120183001.2A05D3A6895@core3.amsl.com>
Date: Tue, 20 Jan 2009 10:30:01 -0800
Cc: wgchairs@ietf.org, ietf@ietf.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

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 mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce