Subject: [newtrk] suggestion for an alternative to newtrk

From: Keith Moore <[email-masked]>
Date: Mon, 2 Feb 2004 16:10:16 -0500

As a possible alternative to newtrk, I offer this suggestion:

Process for Internet Protocol Engineering (pipe)

This working group will define an process for use in Internet protocol
engineering efforts, including IETF working group efforts.   This
process needs to facilitate the production of specifications in such a
manner that the specifications are produced in a timely fashion, and
there is high confidence in the quality and suitability of the output.

It is anticipated that such a process would consist of an ordered series
of steps, each with tangible output that is meaningful to an external
party.  The process would start with an imprecise problem statement,
would be made more precise and then incrementally refined into a set of
design goals.  One or more tentative designs would be outlined in an
attempt to satisfy those goals.  The various designs would be evaluated
and refined, and narrowed to a single design.  That design would be
further refined in various stages based on experience from prototyping, 
interoperability testing, and actual deployment.  At several stages
external review would be solicited and feedback from such review
considered in future refinements of the problem statement, goals, or
specifications.

The working group will produce a recommendation for a process to be used
in engineering Internet protocols, suitable for use by IETF working
groups or independent design teams, and including:

- A list of steps (or states) that a specification may follow,
  with well-defined transitions between states,

- A set of specific technical criteria and review procedures for each 
  state transition, including external (cross-area and/or oversight)
  review at appropriate state transitions or intervals,

- Appropriate mechanisms for publishing documents at each state
  (whether by email, web page, internet-draft, RFC, or some
  other mechanism)

- A set of document labels to be used to indicate that an engineering
  specification has met the criteria for some particular state, and

- The recommended use (whether for prototyping, testing, or deployment) 
  associated with a specification of each state.

This recommendation will consider the entire life cycle of a
specification, from embryonic stages until it is considered obsolete. 

The working group will specifically consider what incentives are likely
to encourage state transitions when they are appropriate (i.e. to
advance a document in grade or to move it to something resembling
"historic"), so that documents do not languish at states that are no
longer appropriate.

The working group will also consider the applicability of various IETF
procedures to these new document states, and define criteria for 
transitions of specifications from existing states (experimental, 
proposed, draft, full, historic) to new states.

This working group is not empowered to unilaterally revise the IETF
standards process; rather it will make recommendations to IESG and to
the community, and present a compelling argument for their adoption.  
IESG will adopt these recommendations if and only when they have been 
tried by several working groups, and refined as necessary, and after 
receiving feedback from the community regarding their effectiveness. 

This working group is not empowered to revise the procedures by which
working groups operate, conduct meetings, discuss issues, or otherwise 
communicate between state transitions.

Schedule:

August 2004:
Produce an internet draft that identifies
a) a (possibly rough) order for development, refinement, use, and
   retirement of internet protocol specifications
b) what general treatment of a specification is to be encouraged at
   each state (review, testing, experimentation, limited use, 
   wide deployment, discontinued use)
c) what potential incentives exist to encourage IETF engineers to
   do the work necessary for state transitions
d) what potential incentives exist for the public to follow the 
   recommended treatment of a specification

February 2005:
Produce an RFC that recommends a "prototype" procedure for working
groups to follow in producing specifications, along with a compelling
argument for why this procedure will improve the ability of IETF to
produce high-quality output in a timely fashion and/or improve
the effectiveness of IETF's document labelling.

At this point the group's output will be subject to review by the
community and by IESG.  If the group's recommendations are well-received,
IESG may elect to continue the group, have it monitor other working
groups using those procedures, and revise the procedures in light of
experience.

--
He not busy being born, is busy dying.		- Bob Dylan
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html