Subject: [its] IETF documents - access conditions, status, advancement

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Feb 2013 17:04:47 +0100

Hello all,

First and foremost, the items below are authoritatively discussed on the
IETF email list at [email-masked].

But following private discussions about ITS, I would like to point out a
few points about IETF, which IMHO are widely known:

- when some IETF person talks mentions a draft, like "draft-byrne-v6ops-
   64share-03" he actually means that draft is available publicly and
   freely, e.g. go to:
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03
   I go download it, check a message format or two and then I object
   publicly about a missing bit at position 3.

   The draft name per se (draft-byrne-v6ops-64share-03) has a
   meaning with respect to its status, group, authority if you wish and
   obviously version.  They are mentioned below.

- most if not all IETF documents are publicly and freely available
   documents.  The most important ones (Request for Comments, Internet
   Drafts) are freely and publicly available - since 1970 until long in
   the future, hopefully.

   Check for example RFC 1 "Host Software", 7 april 1969, at:
   http://www.rfc-editor.org/rfc/rfc1.txt

- an IETF "standard" has a long way before it becomes such.

   First, a personal Internet Draft (I-D) is submitted - an individual
   submission.  The submission is free of charge.  Its title contains
   first Author's last name as second token in the file name,
   e.g. draft-petrescu-blah-blah.  This document
   has not much influence other than maybe raising one or two comments.

   Once submitted, a draft is immediately freely available at ietf.org.
   I submit now, and 2 minutes later my draft is public.  All for free.
   In theory an individual draft is deleted after 6 months since last
   update.  In practice many public archives seem to store these
   forever.

   Please submit drafts.

   Second, if people agree, they form a Working Group.  In this, the
   Charter should define a Work Item.  That Work Item should lead to the
   editing of a WG item draft.  This draft has 'ietf' as the second
   token in the filename, instead of Author's first name,
   e.g. draft-ietf-v6ops-64share-02 (an evolution of the individual
   personal draft-byrne-v6ops-64share-03).

   This WG item has more weight than the individual submission - more
   people agree about it; there's commitment to pursue it, it would
   rarely die.  YEt it's not yet a 'standard'.

   Third, if people agree, they submit it to IESG - a set of experts.
   They deliberate and may kill it, or make it better.

   Then it is a Proposed Standard.  As you see, it's not yet a Standard.

   Then it becomes a Draft Standard.  As you see, it's still not a
   Standard.

   All this process may take anywhere from a few months to several
   years, with the second option being more common.  Some very slowly if
   ever go beyond Proposed Standard status (the case of NEMOv6).

   In addition, there exist alternative Tracks.  The above is the
   Standards Track, but there are also BCP (Best Common Practices),
   Informational and Experimental RFCs, sponsored or not.  Each has its
   peculiarity, but rarely called a Standard.

- the conditions to advance a document are 'rough consensus' - i.e.
   there is some consensus about, it's not just one person, and 'running
   code' - i.e. there is some implementation about it.

- one could write a draft and push it hard - if there's no consensus
   and no code it dies out.

- one could implement, deploy widely, make money of it - if there's no
   consensus it's not an RFC.

Yours,

Alex