On Fri, Jan 3, 2014 at 7:14 AM, The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Creating an IETF Working Group Draft'
<draft-crocker-id-adoption-05.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2014-01-31. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
The productive output of an IETF working group is documents, as
mandated by the working group's charter. When a working group is
ready to develop a particular document, the most common mechanism is
for it to "adopt" an existing document as a starting point. The
document that a working group adopts and then develops further is
based on initial input at varying levels of maturity. An initial
working group draft might be a document already in wide use, or it
might be a blank sheet, wholly created by the working group, or it
might represent any level of maturity in between. This document
discusses how a working group typically handles the formal documents
that it targets for publication.
I think this generally looks good, especially given SM's comments and Dave's replies. A few other minor points:
The process for adoption described in Section 2.1 is obsolete, as I understand it. I believe the current process is to have the authors/editors submit the -00 version to the tracker, and the tracker will block publication until a WG co-chair approves. I also believe the "replaced-by" step is now available via the tracker to WG chairs, so there's no need to contact the secretariat.
The document needs a spell check ("idividual", for example).
Along the lines of the above: What do people think about documents that describe how the tools work, other than the ones that explicitly define the tools? If the datatracker evolves in the near future, the tools-specific remarks of this document could become obsolete. Might it be better to talk about tools-specific processes more in the abstract?
That's all that jumped out at me.
-MSK