Subject: One more take on rfc3932bis

From: Alfred Hönes <[email-masked]>
Date: Fri, 9 Oct 2009 20:55:19 +0200 (MESZ)

All,

after several private discussions, I'd like to communicate
long-standing substantial concerns and conclusions related to
the current version of the
"IESG Procedures for Independent Submission and IRTF Stream" I-D,
<draft-housley-iesg-rfc3932bis-10>.

Preamble:
  "A strong democracy needs a strong opposition"
   (nearly proverbial; found frequently quoted in The Economist, or
   refer to http://www.faqs.org/abstracts/Business-international/
  Italys-weak-right-hand-a-strong-democracy-needs-a-strong-opposition.html)

  The IETF (Process and) Stream needs a strong Independent Submission
  Stream as well.

One of the aims of the Headers and Boilerplates effort was
to get rid of the necessity for IESG Notes in 'normal' cases.
The current draft does mention that in a single sentence in
Section 3, below the list of 5 kinds of conclusions possible:

   The RFC headers and boilerplate is intended to describe the
   relationship of the document to the IETF standards process [N3].  In
|  exceptional cases, when the relationship of the document to the IETF
|  standards process might be unclear, the IESG may provide an IESG note
   to clarify the relationship of the document to the IETF standards
   process, such a note is likely to include pointers to related IETF
   RFCs.  [...]

Subsequently, the draft now has grown to elaborate on this exceptional
case on almost two pages, but it fails to reciprocally establish any
means to protect the two streams independent of the IETF stream from
many kinds of, say, "strange behavior", observed in the past.
(Dave Crocker and John Klensin have recalled such observations
at an abstract level in their recent postings to this list.)
That resulting dis-balance is rather incommensurate.

In order to restore some degree of balance, in the spirit of RFC
4648, I suggest to consider the following additions that should help
to limit the opportunities for abuse and DoS against these streams:

(1)
After the clause quoted above, insert:

||  To ensure the truly exceptional nature of IESG notes, the IESG
||  sets priorities and rate limits the requests to add IESG notes
||  to at most 10% (on average) of the drafts submitted to it under
||  the procedures defined in this document.

[[ Notes:
   a) You might propose another figure than 10% -- arguably this
      conservative proposal is already beyond what usually would
      be regarded as 'exceptional'.
   b) This clause is stated in the form of a self-committment from
      the IESG; it purposely avoids the installation of additional
      procedures for supervision.  Feedback to the NomCom should
      suffice in the long term to give the community an opportunity
      to evaluate and ensure the 'performance' of the IESG w.r.t.
      this goal.
 ]]

(2)
In the 4th-to-last paragraph of Section 3,

   The IESG will normally complete review within four weeks after
   notification by the RFC Editor or IRTF.  [...]

... insert after the quoted sentence:

||  If the IESG does not respond within ten weeks, the ISE or the
||  IRTF, respectively, can firmly assume that conclusion #1 holds.

[[ Note:
   Despite handwaving arguments presented, it should be worth using
   precise terms to avoid confusion, and denote the 'gatekeeping'
   entities of the streams with the names now assigned to them.
   So please replace "RFC Editor" by the more precise "Independent
   Submission Editor (ISE)" wherever that RFC Editor 'function' is
   intended to be denoted -- it most likely will be an independent
   person or team soon.  In this draft, almost all instances of
   "RFC Editor" do not refer to the (abstract) umbrella institution
   still assigned that name, nor to the RSE (which in practice most
   likely will colloquially still be called "the RFC Editor" in the
   future), but to the ISE.
]]

(3)
The intent of conclusion #3 was, and is, to give the IETF 'protected'
time to bring a starting or ongoing effort to success.  Failure of
the IETF (not too rarely not only on the WG level!) to achieve that
success within a reasonable time span should not be able to block a
document forever.  As any other measures of suspension codified in
the IETF process, this decision should have a 'built-in' time limit,
and it should not last indefinitely by default.

Here's my proposal to correct that:

After the paragraph in Section 3 starting with

   The last two responses are included respectively, [...]

insert a new paragraph establishing a timout rule prohibiting
indefinite stalling of documents by conclusion #3; for instance:

|| In the case of the third conclusion, lack of progress in the IETF
|| should not be able to block a document forever.  If the IETF does
|| not arrive at bringing the work denoted as potentially disrupted
|| to a state where publication is granted or extremely likely,
|| within a period of two years from the time of the conclusion
|| suspending the Independent Submisison or IRTF stream document,
|| the ISE or IRTF, respectively, may decide to forward the document
|| for publication anyway.  This timeout can be extended once by
|| another year if the IESG can provide evidence that the IETF effort
|| regarded as colliding with the document has been held off by
|| substantive reasons, but will most likely come to success within
|| this time frame.  If IETF work is not able to make significant
|| progress within such time span, this most likely will be due to
|| personal and or technical disputes that will not disappear in
|| the longer term, making it likely that publication of the original
|| proposal(s) serves to either reconcile the discussion or giving
|| the networking community a clear indication that the IETF effort
|| is probably bound to failure.

Colophon:

 It has been complained frequently that people do not read RFC
 front matter and boilerplate text (including IESG notes) on RFCs.
 According to my observation, what intuitively counts much more for
 such people when judging the relevance of an RFC for their work is
 the RFC number: Higher number is newer; higher number supersedes
 predecessor -- that's a very human built-in pattern of thought!
 Many RFC search engines also return hits in ascending RFC number
 order, irrespective of the status of the memo, potentially adding
 to the misconception.
 Therefore it is fatal that, with extreme likelihood, the documents
 held off by IESG recommendation will ironically be published later
 than the IETF output, with higher RFC numbers, making them appear
 more relevant than the IETF output.
 It might be worth reconsidering the RFC number assignment and
 publication schedule strategies to avoid such potential for
 misconception.  One way to do so would be to publish the held-off
 document(s) in a coordinated manner with the primary IETF output,
 but with lower RFC number(s), and with bidirectional Obsoletes and
 Obsoleted-by entries in the RFC metadata, from the very beginning
 of the lifecycle of these RFCs in the archives.
 If proposal (3) above is accepted, it might even be possible to
 set aside RFC numbers for held-off documents, as soon as that
 happens, because their publication with that number within 3 to 4
 years would be assured (notwithstanding rare exceptional events).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+