Process for moving to Proposed Standard

Here's an update on where we are in the process of moving the DeltaV spec 
to Proposed Standard. All IESG documents start their lives as "Internet 
Drafts".  Standards-track document goes through a number of life-cycle 
phases starting at "Proposed Standard", then progressing to "Draft 
Standard" and finally full "Standard". According to RFC 2026 ("The 
Internet Standards Process -- Revision 3"), a Proposed Standard has the 
following characteristics:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

We have gone through a number of working group last calls, and at this 
time have no outstanding issues. We believe the spec is well understood, 
has received sufficient community review, and has a number of in-progress 
implementations. To make further progress, we need interoperable 
implementations. Implementors, are generally more comfortable dealing with 
stable specifications, hence the reason for Proposed Standard. It provides 
a specification sufficient for implementation and indicates intent to 
progress to full Standard.

The process and rough schedule include:

1. Candidate DeltaV Internet Draft submitted to IETF Application Area 
Directors for initial review - 4/24/2001.

2. The area directors give the document a review and send it back to the 
working group for any changes. The working group will respond to these 
changes through the mailing lists, working group meetings, and or design 
team meetings as necessary. The updated internet draft is then submitted 
to the Area Directors for further review. If there are a number of 
significant changes, we may want to have an additional working group last 
call. 

3. Once the document has been approved by the application area directors, it 
goes out to an IETF wide last call that lasts for a time specified by the 
area director (at least two weeks). The working group will then respond to 
any feedback from the IETF last call, update the spec as needed, 
submitting new Internet Drafts. If the IETF wide last call results in 
significant changes or issues, we may have to cycle through the process 
again to address their issues.

4. Once we have completed the IETF wide last call, the document is 
submitted to the full IESG for consideration as a Proposed Standard. 
Depending on the results of the IESG vote, it may be necessary to update 
the document and resubmit. Once the IESG votes to approve the document, it 
becomes a Proposed Standard, and we're ready to begin moving to Draft 
Standard.

Received on Thursday, 24 May 2001 13:31:09 UTC