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

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Jun 2009 17:47:35 +0300

I am bringing this draft to its second last call. After the completion 
of the headers and boilerplates document and extensive discussions 
within the IESG, it has become clear that several ADs had an issue with 
the 3932bis draft. I have asked Russ to post a new version which I 
believe resolves the issue. However, the changes -- even if small -- 
relate to what information there exists about the status of RFCs in the 
RFCs themselves, so I felt that it this is an issue that needs to be 
taken to the community. I am formally asking for the community review of 
the new version of the draft, but I like to think about this last call 
as a way to find out what the IETF community is thinking about the 
topic. Once we know, I hope we can approve the draft version that 
matches that opinion. Comments should be sent to the [email-masked] 
mailing list.

Note that there has been past discussion of what the header and 
boilerplates should say. This discussion happened on the rfc-interest 
list. 3932bis is about IESG notes and IESG processing, and the notes are 
of course very much related to what the boilerplates have already said. 
However, the boilerplates should be taken as given for the purposes of 
our discussion here. The rfc-interest list had consensus to publish the 
headers and boilerplates in its final form. Only changes to 3932bis are 
under consideration now.

The core of the issue is what non-IETF RFCs say about their relationship 
to IETF. According to the new headers and boilerplates document, the 
source is clearly indicated. However, the issue brought up in the IESG 
review was that this can be insufficient at times. In general, 
additional information about the role of the relationship of the RFC to 
the IETF work would be useful for readers. The new version of the 
3932bis draft suggests that the IESG may add a statement to a non-IETF 
RFC about its relationship to IETF work. Previous language indicated 
that such statements would be exceptional.

The consensus view on the h&b document was that the front matter should 
say what the RFC is, as opposed to saying what the RFC is not. IESG's 
issue with the 3932bis notes under this situation was three-fold. First, 
there is an assumption that the readers are familiar with the different 
streams (what they are and what they're not) -- which many readers of 
RFCs might not be. Second, the relationship between some non-IETF RFC 
and IETF work is often more complex than is captured by just the stream 
and maturity level. Third, additional explanation (not boilerplate) 
specific to the situation could help putting the work in context

The relevant changes from the previous version of the draft are in 
Section 1.1:

OLD:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label eliminates the need for a mandatory IESG note on all 
Independent Submission and IRTF Stream documents.
NEW:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label replaces some of the information that was previously provided 
in mandatory IESG notes on non-IETF-stream documents. The IESG may 
choose to add an IESG note to an Independent Submission or IRTF Stream 
document that explains the specific relationship, if any, to IETF work.

and Section 3:

OLD:
Generally, the RFC headers and boilerplate clearly 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 response may be accompanied 
by a clarifying IESG note and a request that the RFC Editor include the 
IESG note in the document if the document is published.
NEW:
The RFC headers and boilerplate is intended to describe the relationship 
of the document to the IETF standards process [N3]. In addition the IESG 
may request that the RFC Editor include the IESG note to clarify the 
relationship of the document to the IETF standards process, such as 
pointers to related IETF RFCs.

A more detailed diff is available at 
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Jun 2009 17:56:23 +0300

And to start off the comments, I wanted tell my personal opinion about this.

First, I have not been extremely happy with either the h&b or the 
3932bis document, as some people who have been reading the various lists 
may gather. However, I think they were already good enough to be shipped 
before the changes to 3932bis. (And indeed, h&b has been shipped by the 
IAB.) And I can't get that excited about debates regarding the role of 
the various boilerplate texts, because I suspect that the only people 
reading them are the ones who are going to respond to this thread :-)

I do think though that additional information at the level of "This RFC 
describes FOO. A standardized version of FOO can be found from RFC 
NNNN." is useful. I think -07 version of the 3932bis is an improvement 
over the previous one, and should be approved.

Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 01 Jun 2009 11:05:52 -0400

The changes described in your other note (copied after your text to 
preserve context) are reasonable in the abstract.  However, the devil is 
in the details.
As I understand it, the reason for calling the extra note "exceptional" 
is that the IESG has in the past sometimes used that note to place far 
more pejorative language than you suggest, in places that it really does 
not belong.  That can turn a reasoanble publicaiton request into a 
political fight.

In fact, in most cases where there is a published RFC on the same topic, 
the RFC Editor has demonstrated an expectation that the author will 
define accurately and clearly the relationship of their work to the 
existing published work.  So it is not at all clear to me that the case 
you site is even particularly important.

My inclination would be to stick with the "OLD" wording.

Yours,
Joel

> over the previous one, and should be approved.

(From Jari's earlier message...)
The relevant changes from the previous version of the draft are in 
Section 1.1:

OLD:

and Section 3:

OLD:

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Jun 2009 18:30:19 +0300

Joel,

> However, the devil is in the details.
> As I understand it, the reason for calling the extra note 
> "exceptional" is that the IESG has in the past sometimes used that 
> note to place far more pejorative language than you suggest, in places 
> that it really does not belong. That can turn a reasoanble publicaiton 
> request into a political fight.

That's true. However, I think that 3932bis (any version) is already 
supposed to reduce that problem, by not having standard, default 
pejorative language.

The changes in -07 relate to the frequency of notes and their content. 
I'm not sure the frequency matters for avoiding the pejorative language 
problem. If the IESG puts in bad language, they can do so both in -06 
and -07... if you want to solve that problem you need a couple of 
things: first, remove the bad default language. Second, provide a better 
instruction on what the note, if any, should contain. I think -07 is an 
improvement in this respect, because it now talks about the relationship 
of the RFC to IETF and pointers to standards track specifications. 
Third, the IESG folk simply need to have good judgment about using the 
notes. And if they don't, Nomcom should hear about it...

Jari

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Jun 2009 14:09:06 -0400

--On Monday, June 01, 2009 18:30 +0300 Jari Arkko
<[email-masked]> wrote:

>> "exceptional" is that the IESG has in the past sometimes used
>> that  note to place far more pejorative language than you
>> suggest, in places  that it really does not belong. That can
>> turn a reasoanble publicaiton  request into a political fight.
> 
> That's true. However, I think that 3932bis (any version) is
> already supposed to reduce that problem, by not having
> standard, default pejorative language.

Joel, 

I share your concerns.  While I have not yet read -07 carefully,
my sense is that -06 was more satisfactory and that the
substantive differences to -07 tend to reopen doors and
encourage behavior best avoided.   That said, 3932bis is clearly
better than 3932 (at least as it has been interpreted) and I
have to pretty much agree with Jari that the differences don't
amount to anything if one or more ADs decide to misbehave and
the IESG decides to go along.

> The changes in -07 relate to the frequency of notes and their
> content. I'm not sure the frequency matters for avoiding the
> pejorative language problem. If the IESG puts in bad language,
> they can do so both in -06 and -07... if you want to solve
> that problem you need a couple of things: first, remove the
> bad default language. Second, provide a better instruction on
> what the note, if any, should contain. I think -07 is an
> improvement in this respect, because it now talks about the
> relationship of the RFC to IETF and pointers to standards
> track specifications. Third, the IESG folk simply need to have
> good judgment about using the notes. And if they don't, Nomcom
> should hear about it...

Actually, I would hope that, under the new RFC Editor system,
the ISE and/or RSE would feel enabled to appeal every time the
IESG pushes past the kind of evaluation or statements on which
the spirit of both 3932 (as I originally read it) and 3932bis
focus... or to simply ignore the IESG statement/request.
Indeed, I would hope that, unless the reasons for the IESG
statement are clear, that they would feel obligated to do so --
from my point of view, any legitimate situation in which the
IESG feels obligated to make a statement is one in which authors
and the ISE process have failed to make the document and its
relationship to other work clear.  In general, if the problems
are real, it is better to fix documents that exhibit them than
to patch in "statements", regardless of where those are coming
from.   

I hope and trust that it will never be necessary to develop or
invoke procedures in that area.  But, were abuses to occur, I
would hope that there would be a sufficient record of appeals
and the associated discussion to make the issues far more clear
to a relevant Nomcom than just being passed a message.  In fact,
I'd expect an AD who lost one or two such appeals to either
adjust his or her attitudes or resign, without having to wait
for a Nomcom.

I would encourage everyone interested in the topic to study the
RFC Editor Model document, RFCs 4844 and 4846, and any job
descriptions and SOWs to be sure that none of them contain any
language that would prevent the use of the appeals process to
deal with abuses in this area by IESG members.

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Jun 2009 14:39:18 -0400

--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
<[email-masked]> wrote:

> I am bringing this draft to its second last call. After the
> completion of the headers and boilerplates document and
> extensive discussions within the IESG, it has become clear
> that several ADs had an issue with the 3932bis draft. I have
>...
> Note that there has been past discussion of what the header
> and boilerplates should say. This discussion happened on the
> rfc-interest list. 3932bis is about IESG notes and IESG
> processing, and the notes are of course very much related to
> what the boilerplates have already said. However, the
> boilerplates should be taken as given for the purposes of our
> discussion here. The rfc-interest list had consensus to
> publish the headers and boilerplates in its final form. Only
> changes to 3932bis are under consideration now.

But there is one important interaction with what you write
below.  The big change (from today's forms) in Headers and
Boilerplates isn't the identification of the stream.  It is to
permit (very nearly require), statements about review and level
of consensus behind a document.  Those statements are expected
to be factual and (except for the IETF stream) do not depend on
IESG judgments about protocol quality, relationships, etc.
 
> The core of the issue is what non-IETF RFCs say about their
> relationship to IETF. According to the new headers and
> boilerplates document, the source is clearly indicated.

Not just the source, but the level and type of review and
consensus.

> However, the issue brought up in the IESG review was that this
> can be insufficient at times.

Insufficient if only the stream is identified?  Or insufficient
even after a "kind of review and level of consensus" statement
is made?

> In general, additional
> information about the role of the relationship of the RFC to
> the IETF work would be useful for readers. The new version of
> the 3932bis draft suggests that the IESG may add a statement
> to a non-IETF RFC about its relationship to IETF work.
> Previous language indicated that such statements would be
> exceptional.

If the intent is to make them common, I think there is a
fundamental disconnect.    If the intent is to not say
"exceptional" but to treat them that way, then see my earlier
response to you and Joel.

> The consensus view on the h&b document was that the front
matter
> should say what the RFC is, as opposed to saying what the RFC
> is not. IESG's issue with the 3932bis notes under this
> situation was three-fold. First, there is an assumption that
> the readers are familiar with the different streams (what they
> are and what they're not) -- which many readers of RFCs might
> not be. Second, the relationship between some non-IETF RFC and
> IETF work is often more complex than is captured by just the
> stream and maturity level. Third, additional explanation (not
> boilerplate) specific to the situation could help putting the
> work in context

This discussion leads me to wonder whether the IESG has lost
sight of the descriptions of relationships, review, and
consensus for which H&B provides.  Is that possible?

> The relevant changes from the previous version of the draft
> are in Section 1.1:
> 
> OLD:
> The IAB and the RFC Editor have made updates to the formatting
> of the title page for all RFCs [N3]. With these changes, the
> upper left hand corner of the title page indicates the stream
> that produced the RFC. This label eliminates the need for a
> mandatory IESG note on all Independent Submission and IRTF
> Stream documents.
> NEW:
> The IAB and the RFC Editor have made updates to the formatting
> of the title page for all RFCs [N3]. With these changes, the
> upper left hand corner of the title page indicates the stream
> that produced the RFC. This label replaces some of the
> information that was previously provided in mandatory IESG
> notes on non-IETF-stream documents. The IESG may choose to add
> an IESG note to an Independent Submission or IRTF Stream

As written, this violates provisions of RFC 4846 as well as some
of the language in the current RFC Editor Model draft.  The IESG
may _request_ that notes or other language be added.    The ISE
may respond to that by 

	-- adding the notes,
	
	-- handing the document back to the authors with a
	request to address the underlying issues,

	-- adding some other note, presumably with the approval
	of the author(s),
	
	-- withdrawing the document, or 
	
	-- rejecting the IESG request.

In the last case, I would hope that the ISE would provide the
IESG with an explanation.  But nothing we have now requires that
explanation or requires the ISE to engage in a dialogue with the
IESG on the subject.  And, IMO, that is the right balance.  
 
>...

The Section 3 change does not encounter that procedural
objection because it says "...the IESG may request...".

     john

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Jun 2009 21:47:46 +0300

John,

> may _request_ that notes or other language be added.

Indeed -- thanks for catching this. It should say "may choose to 
request" or some words to that effect.

Jari

---

From: Russ Housley <[email-masked]>
Date: Mon, 01 Jun 2009 14:58:23 -0400

>request" or some words to that effect.

I suggest: "The IESG may request the inclusion of an IESG note to an 
Independent Submission or IRTF Stream document that explains the 
specific relationship, if any, to IETF work."

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Jun 2009 15:42:57 -0400

--On Monday, June 01, 2009 21:47 +0300 Jari Arkko
<[email-masked]> wrote:

>> As written, this violates provisions of RFC 4846 as well as
>> some of the language in the current RFC Editor Model draft.
>> The IESG may _request_ that notes or other language be added.
> 
> Indeed -- thanks for catching this. It should say "may choose
> to request" or some words to that effect.

Either that, or Russ's wording, would be fine with me.

I believe that the bottom-line principles here are:

	(1) As above, the IESG requests that the ISE do things;
	it does not insert text or require that text be inserted.
	
	(2) Regardless of whether words like "exceptional"
	appear, the expectation should be that the typical
	independent submission document (or other
	non-IETF-stream document) will contain only the stream
	identification and whatever statements about review and
	consensus go with it, per headers and boilerplates.
	Requests for Additional statements should be unusual and
	very specific to the circumstances of a given document.
	
	(3) There are no statements to the effect that something
	is not an IETF-stream documents or, for that matter, not
	the Constitution of Lower Slobbovia.  I don't think
	those need to be formally prohibited (partially because
	I have no idea how such a rule would be written) but I
	would hope that the ISE and RSE would ignore any such
	request.

My impression has been that all three of those principles had
already achieved consensus, either on the RFC-Internet list or
in the process of reviewing and approving other documents.  Of
course, that impression could be wrong or the broader community
could have something else to say.

best,
   john

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 2 Jun 2009 16:03:28 +0200

On 1 jun 2009, at 16:56, Jari Arkko wrote:

> I do think though that additional information at the level of "This  
> RFC describes FOO. A standardized version of FOO can be found from  
> RFC NNNN." is useful. I think -07 version of the 3932bis is an  
> improvement over the previous one, and should be approved.

The proposed text would allow for these sort of suggestions to be made  
to the Independent Series Editor (ISE, the approval body for the  
Independent Submissions Stream). IMHO these relational notes would be  
useful additions to Independent stream documents. Maybe not even as an  
IESG Note but as language in the abstract and/or introduction.

However, the proposed language would also allow standard templates to  
be added. That would IMHO be wrong.

I understand that for many people the distinction between the various  
streams is not always clear and that a large number of folk think that  
the RFC series is synonymous with Internet Standard documents, but I  
do not think that the IESG Note is the magic bullet to solve that.

In any case:

RFC4846 section 5 uses the word "recommend"
    If the IESG, after completing its review, identifies issues, it may
    recommend explanatory or qualifying text for the RFC Editor to
    include in the document if it is published.

That wording is chosen in such a way that the decision is with the RFC  
Editor, more specifically the ISE. I would try to bring 3932bis in  
line with that:

OLD:
The IESG may choose to add an IESG note to an Independent Submission  
or IRTF Stream document that explains the specific relationship, if  
any, to IETF work.

NEW:
The IESG may recommend [to the RFC Editor] to add an IESG note .....

The text in section 3 uses "request" which IMHO is in line with the  
spirit of 4846. And makes clear that the ISE could in fact push back  
on the recommendation or request.

--Olaf