Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

[John C Klensin <[e-mail]>]

--On Tuesday, 21 October, 2008 08:02 -0700 The IESG
<[e-mail]> wrote:

> The IESG has received a request from an individual submitter
> to consider the following document:
> 
> - 'IESG Procedures for Handling of Independent and IRTF Stream 
>    Submissions '
>    <draft-housley-iesg-rfc3932bis-04.txt> as a BCP

Russ, Harald, and IESG,

While the version listed in the Last Call was -04, I note that
-05 has been posted and my comments are addressed to it.   As a
procedural observation, my recollection is that, for many years,
the IESG has been discouraging posting of new versions of
documents  during Last Call, precisely to avoid confusion about
which version to comment on. 

While this document is much improved from earlier versions, I
believe it is not nearly ready for BCP publication.  I see
sweeping and more specific issues as well as several nits.

Sweeping Issue:

The assertion of "harm" is a very serious one.  We claim that
the Internet is incredibly robust and that there are few
proposed changes that can actually cause significant damage.  If
the places in which "harm" is used in this document are really
intended to mean "contrary to the spirit of the IETF standards
process" or 
even "damaging to the effectiveness of the standards process",
then say that.  Note that the first example in Section 4 is
clearly about something that is problematic for the standards
process with no need to believe that the alternate path is
"harmful to the Internet", while the second one falls into the
category of an inappropriate extension (more discussion on that
below).  Even getting from "hard-to-debug interoperability
problems" to "harm to the Internet" would be a stretch (if the
authors had been able to produce a careful explanation of how to
experiment with those bits in an escape-proof walled garden, the
document might still describe a bad idea, but that would become
a technical judgment --one that this document asserts the IESG
is not supposed to make-- and it would not have been, a priori,
harmful. I believe that the assertion of "harm to the Internet"
is a sufficiently strong one that the IESG should not make it
without clear evidence of community consensus, starting with an
explanation of why it thinks there is a problem (nor merely
asserting "harm") and including an IETF-wide Last Call on the
assertion and explanation.

Specific Issues

(1)  The IESG should never make an assertion that is known to be
false.  This has been an issue since 3932 was published and then
interpreted in a way that several of us did not anticipate; a
revision should not require the IESG to lie (or continue lying).
The fact is that, subject to publication delay, this document
and RFC 4846 permit publication of documents considered by WGs
and rejected.  In addition, some Independent Submissions receive
very extensive review in the IETF.  I hope we are not moving
into the sort of lawyer-land in which formally disclaiming
knowledge --counter to observable fact that the knowledge
exists-- may have a special meaning.  Even if the IESG has not
reviewed a document, it doesn't imply that "the IETF" has not.
If we are not moving to that part of lawyer-land, then it may be
appropriate to say that the IETF takes no position on whether a
document meets certain criteria or that there was no
determination of IETF consensus, but it is not appropriate to
say that the IETF "disclaims knowledge" (or "has no knowledge")
without a case-by-case determination of whether any significant
review within the IETF occurred.

The third paragraph of the Introduction should be modified to
change "are not reviewed" to "are not required to be reviewed"
or equivalent.  The second sentence of that paragraph should be
removed entirely unless the IESG wants to deprive itself of
flexibility to formally ask for community input by prohibiting
the use of Last Calls on Independent Submission drafts (a
flexibility that language in 4846 was intended to preserve).

As a further example of this problem, consider the last
paragraph of the Introduction, where the text talks about the
IESG pushing a document into the Independent stream that had
been "submitted to the IETF".   Such documents are often
reviewed in the IETF before being called to the IESG's attention
via a publication request and then presumably reviewed and
discussed by the IESG (or at least parts of it).

(2) The numbered list in Section 3 is the substantive core of
this document.  "Harmful" in Item 3 is "potentially damaging to,
or problematic for, the IETF Standards Process", not "harmful to
the Internet".   "Potentially" is important there too.  The IESG
should not be expected to foretell possible futures or provide
an analysis of how damage might occur: it should merely have to
have a reasonable basis for believing that WG or other standards
process disruption might occur or that an end-run is being
attempted.

Item 5, when read in the context of paragraph 5 of that section
("The last two...") is a horse of a different color.  Let me
restate what is being said in that Paragraph:    A document
makes it through the standards-track process and is approved,
with community consensus that presumably includes its provisions
for review of changes and extensions, and published.   Some time
later, a document comes along as an Independent Submission that
extends the original spec in some way.   Here, the IESG asserts
its right, without any community review, to say "never mind what
decision was made by community consensus and included in the
original document; we are going to apply a different criterion
entirely".  I believe that, in most cases, the more appropriate
action is to invoke Item 3, ask for a publication delay, and go
back to the community to get consensus for a revised procedure
for signing off on changes or extensions.


Textual nit-picking

* The second full paragraph of the Introduction ("The IETF is
responsible..."), second sentence, should read "..., and any
other IETF-generated Informational or Experimental documents".
Otherwise, one may suck most of the Independent Submission
stream into the IETF stream, contradicting the rest of the
document. Part of the problem with the text that is now in the
document is that there is no clear definition of
"standards-related".

* The document is confused about tense and mood of particular
words  and the general tone of the language used.  For example,
Section 1 Paragraph 5, last sentence, says "...was a
considerable drain... this is not" and should probably should
have been "...this was not".   As another example, consider the
numbered list in Section 3.  The first item says "has not
found", but the others are "The IESG finds".  Note also the
difference between "a finding" and the result of an unsuccessful
search ("we looked for it and didn't find it"). Personally, I
believe that the notion of the IESG making "findings"
excessively judicial -- several of these items are really
statements about the IESG's beliefs--  but that is a matter of
taste.

* The assertion in paragraph 7 of Section 1 is not correct.
While it probably was the case in the years _immediately_
preceding 2006, there was a period of several years in which the
IAB performed a (sometimes pro-forma) review of IRTF
Informational and Experimental documents and then published them
as IAB documents, with minimal or no interaction with the IESG.
Of course, IRTF submissions onto the standards track (if not
entirely prohibited) are outside the scope of this document.

* If you really want to right to claim "harmful to the
Internet", then Section 6 is incomplete, because some of the
classes of harm that you might be trying to prevent involve
security.

* Finally, unless the omission from the Acknowledgments was
intended as an editorial comment, I call your attention to the
rather extensive discussion I participated in about this
document among Jari, Olaf, yourself, and sometimes Leslie and
Harald in early October.   Although I identified the historical
problem with the description of IRTF processes there (a comment
that was apparently ignored, since the problematic text is still
present), several of my comments made it into the document.  I
believe that that the IETF's IPR rules, as well as ordinary
courtesy, require that set of contributions (which certainly
include Jari's) be reflected in the Acknowledgments.   That is
clearly a nit and, at some level, I don't care.   But it also
suggests, especially in context with some of the issues raised
above, that this document has been handled somewhat less
carefully that might be appropriate for something of its
importance.

 regards,
    john



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