Skip to main content

IETF Operational Notes
draft-alvestrand-ipod-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'IETF Operational Notes' to Experimental RFC (draft-alvestrand-ipod-03.txt)

The IESG has approved the following document:
- 'IETF Operational Notes'
  (draft-alvestrand-ipod-03.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Russ Housley.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-alvestrand-ipod/


Ballot Text

Technical Summary
 
   This document describes a new document series (IONs) intended for use 
   as a repository for IETF operations documents, which should be more
   ephemeral than RFCs, but more referenceable than internet-drafts, and
   with more clear handling procedures than a random Web page.

   It proposes to establish this series as an RFC 3933 process
   experiment.
 
Working Group Summary
 
  During IETF Last Call, concern was expressed that ION documents
  must not be used to change matters of IETF process that require
  IETF consensus. This experiment doesn't change the IESG's 
  authority, but it creates a systematic way to document procedural
  decisions. Text was added to clarify that IONs cannot
  override BCPs. The disposition of ION documents if the
  experiment is deemed a failure was clarified, as were other
  points questioned during Last Call. Finally, the IESG needs
  to affirm its support for the experiment.
 
Protocol Quality
 
 Reviewed by Brian Carpenter

Note to RFC Editor

Please update as follows:

OLD
  Old versions MAY be published in the draft store, but there's no
  requirement that they remain available indefinitely.  Experience will
  show what the best policy for draft retention is.

NEW
  Old versions may be published in the draft store, and must be kept
  in a version management system, for the duration of the experiment.
  Experience will show what the best policy for draft retention is
  if the series is made permanent.

OLD
  If someone wishes to do such a split while the experiment is running,
  the BCPs cannot refer to the "procedures" documents as IONs, since
  the concept of an ION may go away.

NEW
  If someone wishes to do such a split while the experiment is running,
  the BCPs cannot refer to the "procedures" documents as IONs, since
  the concept of an ION may go away. In that case, any procedures
  removed from a BCP must either be reinstated or otherwise stored as
  a permanently available reference.

OLD
   o  Web pages, which can be changed without notice, provide very
      little ability to track changes, and have no formal standing -
      confusion is often seen about who has the right to update them,
      what the process for updating them is, and so on.  It is hard when
      looking at a web page to see whether this is a current procedure,
      a procedure introduced and abandoned, or a draft of a future
      procedure.

NEW
   o  Web pages, which can be changed without notice, provide very
      little ability to track changes, and have no formal standing -
      confusion is often seen about who has the right to update them,
      what the process for updating them is, and so on.  It is hard when
      looking at a web page to see whether this is a current procedure,
      a procedure introduced and abandoned, or a draft of a future
      procedure. For certain procedures, their informal documentation
      in the "IESG Guide" wiki has partially clarified this situation
      but has no official status.

RFC Editor Note