Subject: [mif] Last Call: draft-ietf-mif-problem-statement (Multiple Interfaces Problem Statement) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 9 Aug 2010 07:15:51 -0700 (PDT)

The IESG has received a request from the Multiple Interfaces WG (mif) to 
consider the following document:

- 'Multiple Interfaces Problem Statement '
   <draft-ietf-mif-problem-statement-05.txt> as an 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
[email-masked] mailing lists by 2010-08-23. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mif-problem-statement-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19231&rfc_flag=0

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Aug 2010 16:31:45 +0300

Since someone asked about this, I wanted to clarify why and how new 
versions of this draft are being posted while the last call is going on. 
The document has been revised once in order to address two very minor 
details left over from the first round of my AD review (IMO not blocking 
issues), and a second time to address feedback from other reviewers (I 
think). There will future revisions, we just saw a review from Joel 
Halpern that appears to require a small change, for instance.

There are a couple of different ways of doing this in the IETF, but my 
personal model is to ask the authors to address feedback as soon as it 
becomes known -- even during last call. We should of course always 
carefully evaluate whether the feedback leads to document changes -- not 
all feedback does. At times we are even a bit too eager to please the 
reviewer in the IETF. But in my mind, if we end up deciding that 
something is missing or wrong, I think it is beneficial to everyone that 
the document is updated in a timely manner. As a reviewer I do not like 
to re-discover the same bugs that others have already found, and as an 
IESG reviewer I appreciate that I can see that issues from last call 
reviews were addressed. I think these benefits outweigh the cost of 
having a bit of a moving target.

(As a side note, all this would be more fun if the last call e-mails 
held a stable tools URL rather than point to the current version: 
http://tools.ietf.org/html/draft-ietf-mif-problem-statement)

Jari