[edu-team] Document Lifecycle Tutorial - IETF 72

[Alice Hagens <[e-mail]>]

EDU Team,

The slides for the document lifecycle tutorial are posted here:
   ftp://ftp.rfc-editor.org/in-notes/rfc-editor/lifecycle72.pdf

Please let me know if you have any changes to the content. It has  
been slightly updated since it was presented at IETF 70. The list of  
questions that we received at that time is below.

Thank you.

Alice
for the RFC Editor

> Document Lifecycle Tutorial
>
> Presented by: Alice Hagens and Margaret Wasserman
>
> Sunday, July 27, 2008 - 15:00-16:45
> ===================================
> Room:
>
> This tutorial offers an overview of producing documents in the IETF,
> from version 00 of an Internet-Draft to publication as an RFC.  We
> will cover the working group process, and the required and suggested
> contents of an Internet-Draft, including information from IANA staff
> about writing IANA Considerations sections.   We will walk through
> the lifecycle including authorship, WG draft, IETF Last Call, IESG
> evaluation, and what to expect during the RFC publication process.
> We will provide a set of helpful hints to authors about formatting
> rules and editorial policies that often improve the quality of the
> resulting documents.  We will summarize the states of the RFC
> publication process and provide an opportunity to ask questions of
> RFC Editor staff.
>

-----------------------------------------------------
// Q&A at the Document Lifecycle Tutorial
// IETF 70, December 2, 2007

Q1. If we want to update an RFC that was written by another author,
should the author of the previous RFC be listed in the header as an
author of the new RFC, because it sounds like publication could be
held up if author is unavailable during AUTH48?

A1. This has been done in various ways.  In the best case scenario,
you want to work this out with the previous author.  However,
the authors of a previous version of a document are typically listed
in the acknowledgements or contributors section.  We usually like to
see just the active editors/authors listed in the header of an RFC,
becauase all individuals listed in the header of a document are
required to approve the document prior to RFC publication.


Q2. Would it be appropriate to write a new RFC to update the references
of an old RFC?  Using 6MAN as an example, there is no work currently
being done, but we want to update the RFC to refer to more current
work.

A2. We don't usually recycle documents for the sole purpose of
updating references.  However, if a new document is written to correct
something in the older RFC, then the references must be updated.

Note that there is no policy for or against updating the document for
this purpose.


Q3. You said it's possible to have a status change in the archive
without creating a new document?  How is this done?

A3. This is done in instances for which an RFC has been published, and
the IESG/community later approves a status change that does not
require publishing a new document.  For example, a document that was
published as a Proposed Standard, can later become a Draft Standard
if there are no changes required to the specification.  This requires
only a change in the RFC Editor index.


Q4. Can normative references refer to standards track documents only?

A4. This is a misconception; normative references are those documents
that are required reading for implementation and understanding of the
current specification.  The RFC Editor is only concerned that
1. all references have corresponding textual citations, and
2. references refer to the most current RFC on the topic.

There is a "downref" policy that requires that Standards Track documents
normatively reference documents of equal status or higher (e.g., a
Proposed Standard should not have a normative reference to an
Experimental document).  However, there are exceptions to this policy;
See BCP 97, RFCs 3967 and 4897.

Suggested fixes to keep your document from being held because of
normative references:

a. Often times, you want to check to ensure that normative referencs
actually need to be listed as a normative reference.

b. Include the relevant excerpt from the lower-level RFC to
get rid of the downref.


Q5. What is a MIB and what is bis?

A5. MIB stands for management information base, which is a formal
description of a set of network objects that can be managed using the
Simple Network Management Protocol (SNMP). The format of the MIB is
defined as part of SNMP. (All other MIBs are extensions of this basic
management information base.)  Please see RFCs 1155, 1157, and 1213
for more information.

bis is an old ISO term that we adopted in the IETF.  It is a Latin
term that means "again" or "twice".  In the IETF context, it is used
to mean a revision of a previous document (e.g.,
draft-ietf-sieve-3431bis-04 is an Internet-Draft that is intended to
obsolete RFC 3431).

Note that the newly published document (draft-ietf-sieve-3431bis-04)
will receive a new RFC number; it will not be republished as RFC 3431.


Q6. Is there a tool to convert text to XML?  We lost our source file.

A6. xml2rfc converts XML to text, nroff, HTML, or XML; at this time, the
reverse tool (text-to-XML conversion) does not exist.

Bill Fenner suggests trying the configuration for the XMLMind XML
editor that he has been developing.  It still requires manual work,
but it is less work than starting from scratch.
See: http://code.google.com/p/xml2rfc-xxe/


Q7. Why doesn't I-D submission require submission of the XML source as
well?

A7. Not all authors use XML to create their document.  The RFC Editor
does not care about how the document was created; authors can use any
editor they prefer as long as it outputs a text file.


Q8. Is it appropriate to write documents to clarify a set of older
documents?

A8. There are different answers for this; some revisions have been
accepted by working groups and published as RFCs, and others have been
shot down by the working group.  There no policy on this.


Q9. Will an AD-sponsored or an Independent submission be fast-tracked?


A9. Neither is a fast-track. The time it takes for your document
to move through either process depends on a number of
variables (e.g., the technical content, the editorial quality,
your responsiveness to comments).

For information on the AD-sponsored process, see:
http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html

For information on the Independent submission process, see:
http://www.rfc-editor.org/indsubs.html
After reviewing a document (and typically going through
iterations with the authors), if the RFC Editor agrees an
Independent submission is ready to be published, it goes to a
4-week TimeOut (TO) state for the IESG to review for conflict
with work in working groups. They make a publish or
do-not-publish recommendation. The final publication decision is
made by the RFC Editor; however, it is very unlikely that the
recommendation of the IESG will not be honored.

_______________________________________________
edu-team mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/edu-team