5. Examples of Cases Where Publication Is Harmful

   This section gives a couple of examples where delaying or preventing
   publication of a document might be appropriate due to conflict with
   IETF work.  It forms part of the background material, not a part of
   the procedure.

   Rejected Alternative Bypass: A WG is working on a solution to a
   problem, and a participant decides to ask for publication of a
   solution that the WG has rejected.  Publication of the document will
   give the publishing party an RFC number to refer to before the WG is
   finished.  It seems better to have the WG product published first,
   and have the non-adopted document published later, with a clear
   disclaimer note saying that "the IETF technology for this function is
   X".

   Example: Photuris (RFC 2522exp), which was published after IKE (RFC
   2409(-> 4306prop)).

   Inappropriate Reuse of "free" Bits: In 2003, a proposal for an
   experimental RFC was published that wanted to reuse the high bits of
   the "fragment offset" part of the IP header for another purpose.  No
   IANA consideration says how these bits can be repurposed, but the
   standard defines a specific meaning for them.  The IESG concluded

   that implementations of this experiment risked causing hard-to-debug
   interoperability problems and recommended not publishing the document
   in the RFC series.  The RFC Editor accepted the recommendation.

   Note: in general, the IESG has no problem with rejected alternatives
   being made available to the community; such publications can be a
   valuable contribution to the technical literature.  However, it is
   necessary to avoid confusion with the alternatives the working group
   did adopt.

   The RFC series is one of many available publication channels; this
   document takes no position on the question of which documents the RFC
   series is appropriate for.  That is a matter for discussion in the
   IETF community.