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

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Aug 2009 23:25:12 -0600

On Jun 2, 2009, at 8:03 , Olaf Kolkman wrote:

>
> 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.

Olaf, I believe this means in the contents of the document. I am under  
the understanding the the IESG Note in RFC is provided by the IESG not  
by the RFC Editor. Is there a document that says otherwise? (I'm  
certainly open to the possibility that perhaps these documents should  
not have an IESG note but that seems a different issue)

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Aug 2009 11:56:46 -0400

>not have an IESG note but that seems a different issue)

My understanding of this text is that the IESG can recommend text, 
including an IESG Note.  The RFC Editor can accept it or not.  The 
RFC Editor has a lot of discretion here.  To date, the RFC Editor has 
never rejected an IESG Note.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2009 13:16:53 +1200

On 2009-08-28 03:56, Russ Housley wrote:
> including an IESG Note.  The RFC Editor can accept it or not.  The RFC
> Editor has a lot of discretion here.  To date, the RFC Editor has never
> rejected an IESG Note.

I'm pretty sure, though, that there has been pushback and negotiation
on quite a few occasions. It's important that the RFC Editor keeps
this power, in the general interest of checks and balances. By the time
an RFC comes out, it's too late for an appeal process to affect the
outcome. So I find the current text of 3932bis completely appropriate.

    Brian

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Aug 2009 19:13:22 -0700

>>>>  I am under
>> including an IESG Note.  The RFC Editor can accept it or not.  
...
> this power, in the general interest of checks and balances. 

+1.

One can debate various details and costs about the RFC Editor function.  But it 
really is quite useful to have the editor exert an independent review of IESG 
efforts to modify an RFC.

Not because the IESG is suspect, but because it is deeply involved in the topics 
it comments on and that could cause misguided decisions.  By contrast, the RFC 
Editor can consider suggested IESG notes with detachment.

My impression, too, is that this has produced revised IESG text.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 28 Aug 2009 10:55:39 +0200

>>> including an IESG Note.  The RFC Editor can accept it or not.

As Russ said: the IESG can suggest text, which can be an IESG note.  
The RFC Editor, more specifically the Independent Submission Editor,  
is responsible for the followup, which includes the possibility of the  
variation described below.

FWIW (and in my no-hats opinion) this 'negotiation' between IESG and  
ISE should all happen well before the RFC is submitted to the  
production center and the RFC Series Editor (RSE) should in general  
not be part of this loop. Only if the ISE and the IESG cannot come to  
agreement then the RSE is called in as described in RFC5620 section  
4.1.3.

> One can debate various details and costs about the RFC Editor  
> function.  But it really is quite useful to have the editor exert an  
> independent review of IESG efforts to modify an RFC.
>
> Not because the IESG is suspect, but because it is deeply involved  
> in the topics it comments on and that could cause misguided  
> decisions.  By contrast, the RFC Editor can consider suggested IESG  
> notes with detachment.
>

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2009 10:59:58 +0100

>>> I am under
>>> the understanding the the IESG Note in RFC is provided by the
>>> IESG not by the RFC Editor. Is there a document that says
>>> otherwise? (I'm certainly open to the possibility that perhaps
>>> these documents should not have an IESG note but that seems
>>> a different issue)

Right, I don't think the RFC Editor can vary the IESG note without IESG 
agreement (otherwise it would not be an IESG note, it would be an RFC Editor 
note).

So, at the crunch (loggerheads) the RFC Editor is faced with the choice of 
including the note or not.

The debate (AFAICS) is about whether the IESG can require a note to be 
included or whether the RFC Editor is free to leave the note out.

Dave Crocker said...

> One can debate various details and costs about the RFC Editor function.
> But it really is quite useful to have the editor exert an independent 
> review
> of IESG efforts to modify an RFC.
>
> Not because the IESG is suspect, but because it is deeply involved in the
> topics it comments on and that could cause misguided decisions.  By
> contrast, the RFC Editor can consider suggested IESG notes with
> detachment.
>

I *do* agree that letting the RFC Editor debate the content of the note is 
very valuable. As Dave says, the RFC Editor can bring independence and 
detachment. But I would like for this to be a debate/negotiation. If the RFC 
Editor (for whatever good reason) wishes to leave the note out and the IESG 
wishes (for some other equally good reason) to leave the note in, we need to 
be able to resolve the conflict.

Options clearly are:
- RFC Editor has the power
- IESG has the power
- A third party (RSE?) has the power
- IESG and RFC Editor are required to reach consensus

We do need the community to make this decision.

Adrian

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 28 Aug 2009 08:10:39 -0700

Adrian Farrel wrote:
>       But I would like for this to be a debate/negotiation. If
> the RFC Editor (for whatever good reason) wishes to leave the note out 
> and the IESG wishes (for some other equally good reason) to leave the 
> note in, we need to be able to resolve the conflict.
> 
> Options clearly are:

The fact that the RFC Editor has not yet completely denied an IESG desire to 
have a note affixed to a draft is significant.  And it's expensive to define 
another layer of mechanism, like appeal to a third party.  And independence of 
the RFC Editor seems to generally be a Good Thing.

If the RFC Editor were to refuse adding a note, what is the likelihood that this 
would be due to making a horribly wrong decision?  And what is likely to be the 
real damage from it?

There is plenty of subjective indication that RFC readers are not nearly as 
careful as any of us would like.  Adding IESG Notes is an appropriate matter of 
due diligence, but in the extraordinarily rare -- ie, unlikely -- case of a 
refusal to add, do we really need a special mechanism?  Is the likely damage 
that great?

The RFC Editor already has significant accountability.  If it made a refusal 
that was inappropriate, there would probably be a deeper problem to deal with.

So I 'vote' for a simple choice:  The RFC Editor has the power.

d/

-- 

   Dave Crocker

---

From: Jari Arkko <[email-masked]>
Date: Mon, 31 Aug 2009 16:29:26 +0300

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last call 
in June because several IESG members felt uncomfortable with the IESG 
notes being used only in exceptional circumstances. I asked Russ to 
prepare the -07 version. This version allowed notes to be used at the 
IESG's discretion and suggested that the linkage (or lack thereof) to 
IETF work would typically be explained in the note. This version was 
taken to the second last call.

While the number of comments we received was small, after the last call 
was over I determined that the consensus was against this change. As a 
result, I asked Russ to prepare the -08 version. This version goes back 
to the "exceptional" wording from -06, but incorporated a number of 
editorial corrections that had been made in interim. I also took the 
draft back to the IESG telechat last week. The IESG was not extremely 
pleased with the new version, but my understanding is that they were 
willing to accept the changes. However, a new issue was brought up: one 
of the changes that Russ and I felt was editorial highlighted the fact 
that the document makes the IESG notes a recommendation to the RFC 
Editor, not something that would automatically always be applied to the 
published RFC. Some IESG members were concerned about this, and 
preferred the latter.

And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that is 
always applied to the published RFC. Please reply before the next IESG 
meeting on September 10. Some e-mails on this topic have already been 
sent in the Last Call thread -- I have seen those and there is no need 
to resend.

(For the record my own slight preference is b. But I have to say that I 
think the document has been ready to be shipped from version -06, and 
its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)

Jari Arkko

---

From: Brian Rosen <[email-masked]>
Date: Mon, 31 Aug 2009 10:59:48 -0400

Following a request to look at this document, and with only a cursory look
at the archives, I'm confused.

The note is always intended to be included in the document itself, right?

Is this change designed to compel, as opposed to request, the RFC Editor to
include the note?

If the answer to those is yes, then I support the change.  The RFC Editor is
not selected to make judgments on whether a note from the IESG should, or
should not be included in a document.  It's not an editorial judgment, it's
is a technical concern.

However, I think some form of appeal is needed, perhaps to the IAB, that
would allow authors some measure of control of what goes in their document.

Brian

On 8/31/09 9:29 AM, "Jari Arkko" <[email-masked]> wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2009 11:25:52 -0400

--On Monday, August 31, 2009 10:59 -0400 Brian Rosen
<[email-masked]> wrote:

> Following a request to look at this document, and with only a
> cursory look at the archives, I'm confused.
> 
> Is this change designed to compel, as opposed to request, the
> RFC Editor to include the note?
> 
> If the answer to those is yes, then I support the change.  The
> RFC Editor is not selected to make judgments on whether a note
> from the IESG should, or should not be included in a document.
> It's not an editorial judgment, it's is a technical concern.

Brian,

Remember that 3932bis applies to the Independent Submission
stream, not to IETF documents of any flavor.  These are, in
general, documents that have not been formally reviewed in the
IETF (although many of them have been extensively discussed).
They are not IETF Stream documents, about which, subject to
push-back from WGs and the community, the IESG can do pretty
much as it likes.

For these documents, there is no IETF Last Call.  If the IESG
creates a note, that note reflects the individual judgments of
the ADs (and presumably IESG review and approval of those
judgments) and not the rough consensus of the IETF community.
Given that, while it may be a "technical concern" (or at least
reflective of a technical preference), it is a concern from (at
most) a group of individuals who happen to be on the IESG; there
is no requirement that it represent a technical concern from the
IETF community.  

In that context, what you are really asking for is that the
preferences or concerns of that group of individuals --
preferences that they could not get the RFC Editor or document
authors to accept through normal review channels -- override the
decision-making process and approval of a non-IETF stream.
Especially since we expect documents in the Independent
Submission stream that would carefully criticize or provide
alternatives to IETF-approved approaches (see RFC 4846), giving
the IESG that much authority, especially without consulting the
IETF Community and determining consensus, does not seem sensible
or consistent to me.  Indeed, it seems like a mechanism for
permitting only authorized dissent.

YMMD.

    john

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Aug 2009 10:34:52 -0500

I have a serious concern about the impact of this decision and the 
perception of RFCs by the community that uses the output of the IETF.

The IETF process has a number of very strong safeguards in place to 
ensure that the protocols we publish have certain levels of quality and 
safety built in, and the Internet community at large has grown to 
associate that level of quality with the RFC series.

While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.

In particular, when a user accesses a document at a url of the form 
<http://www.ietf.org/rfc/rfcNNNN.txt>, there is going to be a strong 
presumption on their part that the document was produced by the IETF. In 
the cases that this presumption is incorrect, it seems tantamount to 
deception to tuck the distinction between IETF and non-IETF documents 
away in an obscure header field.

/a

Jari Arkko wrote:
> But first some background. This draft was brought to a second last 
> call in June because several IESG members felt uncomfortable with the 
> IESG notes being used only in exceptional circumstances. I asked Russ 
> to prepare the -07 version. This version allowed notes to be used at 
> the IESG's discretion and suggested that the linkage (or lack thereof) 
> to IETF work would typically be explained in the note. This version 
> was taken to the second last call.
>
> While the number of comments we received was small, after the last 
> call was over I determined that the consensus was against this change. 
> As a result, I asked Russ to prepare the -08 version. This version 
> goes back to the "exceptional" wording from -06, but incorporated a 
> number of editorial corrections that had been made in interim. I also 
> took the draft back to the IESG telechat last week. The IESG was not 
> extremely pleased with the new version, but my understanding is that 
> they were willing to accept the changes. However, a new issue was 
> brought up: one of the changes that Russ and I felt was editorial 
> highlighted the fact that the document makes the IESG notes a 
> recommendation to the RFC Editor, not something that would 
> automatically always be applied to the published RFC. Some IESG 
> members were concerned about this, and preferred the latter.
>
> note is just a recommendation to the RFC Editor or (b) something that 
> is always applied to the published RFC. Please reply before the next 
> IESG meeting on September 10. Some e-mails on this topic have already 
> been sent in the Last Call thread -- I have seen those and there is no 
> need to resend.
>
> (For the record my own slight preference is b. But I have to say that 
> I think the document has been ready to be shipped from version -06, 
> and its unfortunate that we're not there yet, particularly since this

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 12:05:42 -0400

Before commenting on the question, I wish to comment slightly on the 
exposition.  While I understand that some IESG members were surprised 
that the text brought to them treated IESG notes as a recommendation to 
the RFC Editor, such surprise gap in historical information rather than 
a change.  That text was not a change in practice.  The documented rules 
and practice has long been that with regard to Independent Submissions 
the IESG notes are a request / recommendation to the RFC Editor (soon to 
be ISE), not a statement of what will be included in the result.

Based on having seen a number of IESG notes, and reading the resulting 
text and its inherent tone, I would strongly prefer that IESG notes be 
an exception.  Also, I believe that the stream identification and 
associated indications are quite sufficient for the normal case.  Unless 
we wish to deliberately denigrate the Independent Submissions tream, we 
should not be putting extra notes on the front of them.  I consider the 
Independent Stream to be an important source of information and 
commentary that helps the overall internet process, and would be very 
unhappy to see it denigrated.

Thus, I strongly prefer (a).   I prefer that such notes be rare, and 
that they remain recommendations to the ISE.

Even if the IAB were to agree that such notes should be common, I would 
strongly recommend that the tone and content of such notes remain at the 
discretion of the ISE.  Otherwise, there is no true Independent series.

Yours,
Joel M. Halpern

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Aug 2009 17:20:09 +0100

> that they remain recommendations to the ISE.

+1 to that,

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 12:24:36 -0400

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.
This is a fair concern.
But the same could be said all our experimental and informational RFCs. 
  Should we insist that all experimental and informational RFC, even 
from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?
(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.

While it is important to note when experimental or informational 
documents have had community review, and when they haven't, I do not see 
that the distinction, for these documents, warrants denigrating outside 
comment and input.

Remember also that in terms of the text being a recommendation, this is 
not a change in practice.  This is the practice we have had for more 
than the last 15 years.  If, for Independent Submissions, it is that big 
a problem, I would expect ot have heard of it.

Also, to pick up a comment from Robert, and reinforce and answer from 
John, in providing an IESG note for an Independent Submission, the IESG 
is not shining the light of IETF consensus (rough or otherwise) on the 
document.  While I strongly respect the IESG judgment, and want them to 
keep using and applying that judgment, I do not think it fair to 
conflate that with reflecting IETF consensus on something where there no 
source for such consensus.  (For clarity, I do want the IESG to have the 
opportunity to make their recommendation, and I want it taken serious by 
the ISE / RSE.  This is because they do have a view of the IETF activity 
picture, and can provide necessary perspective and judgment about the 
relationships among the moving parts.  But let us not induce confusion 
by assigning that judgment inappropriate grounding.)

Yours,
Joel

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 31 Aug 2009 09:27:09 -0700

Joel M. Halpern wrote:
>     The documented rules 
...
> an exception.  
...

+1.

It might help folks to understand the independent relationship, between the 
IETF/IESG and these other RFC streams, if the title of this draft were changed 
from "Handling of" to "Assisting with".

d/

-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Mon, 31 Aug 2009 12:39:09 -0400

Yes, I understand, this only applies to the Independent Submission stream.

We ask the IESG to review these documents, and that review is technical.

I don't think it is appropriate for an editor to make a judgment of whether
a technical note is, or is not appropriate to be included in a document.  I
think the presumption should be that it is appropriate, and the authors have
a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their ability to
make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF consensus call.

Brian

---

From: Bob Braden <[email-masked]>
Date: Mon, 31 Aug 2009 10:30:52 -0700

Adam Roach wrote:

> presumption on their part that the document was produced by the IETF. 
> In the cases that this presumption is incorrect, it seems tantamount 
> to deception to tuck the distinction between IETF and non-IETF 
> documents away in an obscure header field.
>
> /a

Your argument seems to me to be the latest version of the 30-year old 
discussion about whether all
RFCs are standards.   They are not.  And even documents in the IETF 
stream (which includes
individual submission, by the way) very considerably in quality and safety.

Bob Braden

>> the IESG's discretion and suggested that the linkage (or lack 
>> thereof) to IETF work would typically be explained in the note. This 
>> version was taken to the second last call.
>>
>> call was over I determined that the consensus was against this 
>> change. As a result, I asked Russ to prepare the -08 version. This 
>> version goes back to the "exceptional" wording from -06, but 
>> incorporated a number of editorial corrections that had been made in 
>> interim. I also took the draft back to the IESG telechat last week. 
>> The IESG was not extremely pleased with the new version, but my 
>> understanding is that they were willing to accept the changes. 
>> However, a new issue was brought up: one of the changes that Russ and 
>> I felt was editorial highlighted the fact that the document makes the 
>> IESG notes a recommendation to the RFC Editor, not something that 
>> would automatically always be applied to the published RFC. Some IESG 
>> And now back to the input that I wanted to hear. I would like to get 
>> a sense from the list whether you prefer (a) that any exceptional 
>> IESG note is just a recommendation to the RFC Editor or (b) something 
>> that is always applied to the published RFC. Please reply before the 
>> next IESG meeting on September 10. Some e-mails on this topic have 
>> already been sent in the Last Call thread -- I have seen those and 
>> there is no need to resend.
>>

---

From: Bob Braden <[email-masked]>
Date: Mon, 31 Aug 2009 10:39:01 -0700

> We ask the IESG to review these documents, and that review is technical.
It seems important to begin a discussion with true facts, and the 
statement immediately above is false.
To quote Harald's words from RFC 3932:

   In March 2004, the IESG decided to make a major change in this review
   model.  The new review model will have the IESG take responsibility
   ONLY for checking for conflicts between the work of the IETF and the
   documents submitted; soliciting technical review is deemed to be the
   responsibility of the RFC Editor.  If an individual IESG member
   chooses to review the technical content of the document and finds
   issues, that member will communicate these issues to the RFC Editor,
   and they will be treated the same way as comments on the documents
   from other sources.

Sigh. I suppose this message is a derivative work.

Bob Braden'

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Aug 2009 12:56:34 -0500

> I think it would be okay to have the note go through an IETF  

+1 , including the "IETF consensus call" part.

(...and to venture into the water under the consensus bridge part of  
the discussion...)

Joel wrote:

> If I understand your note properly, your primary concern is that  
> folks will think that Independent submission are IETF products.
> This is a fair concern.
> But the same could be said all our experimental and informational  
> RFCs.  Should we insist that all experimental and informational RFC,  
> even from IETF WGs, carry big warnings "THIS IS NOT AN IETF  
> STANDARD." Repeated multiple times to make sure folks do not miss it?
> Wed try very hard to make it clear to folks that there is a  
> difference between standards track documents and non-standards track  
> documents. Independent Stream documents are not standards track  
> documents.

And we fail miserably in those cases too.

Since I first started contributing in the IETF, I have on countless  
occasions had to explain to people who don't participate that some  
given RFC is not a standard. To most of the world, RFC==standard.  
Maybe putting "THIS IS NOT AN IETF STANDARD" all over the place would  
help, but I'm not sure about even that. Even worse, I have personally  
seen multiple instances of marketing people intentionally introducing  
FUD by talking about compliancy to some non standards-track RFC. (or  
even an ID that had been actively deprecated by the relevant working  
group.) Personally, I think our first mistake was using the same  
document name prefix for the different streams.

I am most particularly concerned about the case where a draft that was  
presented to a work group that selected not to publish it, and then  
later gets published in the independent stream.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 14:09:48 -0400

If we really feel that the current approach does not make non-standards 
clear enough, then we should address that for all experimental or 
informational documents.  It is basically unrelated to the Independent 
Stream issue.

With regard to documents that are alternatives to existing IETF work, 
the RFC Editor has always required, as is appropriate for any academic 
work, a description of the relationship to existing work.  Reviewers who 
know the area and work are selected.  Thus, the document, in its text, 
is expected to explain why it is different from the standard.  Which 
also requires it to be clear that it is different from the standard.

Handling such discrepancies in the document is both clearer, more 
effective, and fairer to the authors than trying to solve the problem by 
slapping a note on the front of the document.

And before someone says "but the ISE is not requrie to do that", note 
that the ISE is required to maintain the quality of the stream.  That 
includes ensuring that there is suitable description of the relationship 
to existing work.  So not only is this the current practice, but it is 
part of what we can reasonably expect.

I guess this relates to a lot of my problem with this whole "mandatory 
IESG notes" approach.  If there is a real problem with the document, 
then the document should address the problem.  If the IESG does not like 
the light the document puts the IETF into, then we probably made a 
mistake earlier, and this is not the place to fix it.
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.

Yours,
Joel

Ben Campbell wrote:
> (...and to venture into the water under the consensus bridge part of the 
> discussion...)
> 
> Joel wrote:
> 
>> even from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
> occasions had to explain to people who don't participate that some given 
> RFC is not a standard. To most of the world, RFC==standard. Maybe 
> putting "THIS IS NOT AN IETF STANDARD" all over the place would help, 
> but I'm not sure about even that. Even worse, I have personally seen 
> multiple instances of marketing people intentionally introducing FUD by 
> talking about compliancy to some non standards-track RFC. (or even an ID 
> that had been actively deprecated by the relevant working group.) 
> Personally, I think our first mistake was using the same document name 
> prefix for the different streams.
> 
> later gets published in the independent 
> stream._______________________________________________
> Ietf mailing list
> [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Aug 2009 13:20:45 -0500

> to be subject to community review.

Given this fact, why is there pushback on the idea that we would 
prominently mark the documents to indicate that they have not been 
subjected to community review? It seems like the kind of thing that is 
of extreme relevance to the reader.

/a

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2009 14:23:06 -0400

--On Monday, August 31, 2009 10:30 -0700 Bob Braden
<[email-masked]> wrote:

> Your argument seems to me to be the latest version of the
> 30-year old discussion about whether all RFCs are standards.
>...

Not quite 30 years, because it took us a while to start using
terms like "standard", and even longer to get the IETF into
existence into existence.  But, as part of that long argument it
is worth reminding those those think that non-standards RFCs
should be published in a different series that the IETF, after
it was created, decided to publish its standards-track documents
in the RFC Series.  It isn't as if the other documents were
somehow grafted on -- it is the IETF standards-track materials
that were grafted on to what was previously an
almost-all-independent-submissions situation (there were a few
IANA and IAB documents in the series too).   I know you know
that, but others seem to forget, and to do so fairly regularly.

The Headers & Boilerplate document is supposed to help with the
identification situation by explicitly identifying the streams
and the role of each.  If those warnings are not sufficient, it
is not clear to me that boilerplate notes, of the variety that
RFC 3932 has been read as calling for, will help much.

>...
> And even documents in the
> IETF stream (which includes

Hmm.  I have a counter-proposal to those IESG members who
believe in their right to include negative-sounding comments
about independent submission documents without explaining the
reasons for their objections (or, often, even the objections
themselves) or taking responsibility for those objections by
signing  their names or at least putting explicit information
into the tracker.  

The current RFC Editorial Board contains significant expertise
and does review the Independent Submission documents for
technical adequacy.  If IESG membership is a special
qualification, it is worth noting that the Editorial Board's
membership includes several former ADs and even two former IETF
Chairs.  

How about we start Editorial Board review of all IETF Stream
documents arriving from the IESG and, where the Editorial Board
deems it appropriate, attaches notes that reflect on the quality
and/or safety of the ideas suggested.   I imagine that the
Editorial Board would at least be willing to be specific about
objections and to sign specific notes, unlike, at times, the
IESG.

Let the second-guessing begin!

No, not really.... it is a terrible idea and I can't imagine
most Editorial Board members having time, but perhaps it makes
the point.

    john

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Aug 2009 13:29:41 -0500

> Independent Stream documents are not standards track documents.

And I agree that there is an issue of the community not distinguishing 
among standards-track, informational, and experimental documents. But 
that's a separable problem that is, in my opinion, of much smaller 
consequence.

I assert that the distinction between these classes of documents is 
much, much smaller than the distinction between IETF-reviewed documents 
and independent stream documents.

> Remember also that in terms of the text being a recommendation, this 
> is not a change in practice.  This is the practice we have had for 
> more than the last 15 years.  If, for Independent Submissions, it is 
> that big a problem, I would expect ot have heard of it.

Perhaps I'm just unclear on the frequency of independent submissions -- 
but can you find me an RFC that came from a source other than the IETF 
that does not include a prominent note indicating that fact?

I'm under the distinct impression that historical practice tagged all 
(or almost all) such documents with a prominent note. The proposed 
procedure tries to make this an extreme exception, not the norm.

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 14:30:46 -0400

If every document needs this marking, then that is a matter for headers 
and boilerplates.  I can understand arguing about how we mark documents.
If our headers and boilerplate are not sufficient, then we should 
renegotiate them.  I personally think that they are about as good as we 
can get.

But the IESG review is for checking for conflicts with IETF work.  It is 
for reporting such conflicts.  It is not a general review for "does the 
IETF like this work."

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2009 14:35:22 -0400

--On Monday, August 31, 2009 13:20 -0500 Adam Roach
<[email-masked]> wrote:

> Joel M. Halpern wrote:
>> And given that these are Independent Submissions, they aren't
>> supposed  to be subject to community review.
> 
> Given this fact, why is there pushback on the idea that we
> would prominently mark the documents to indicate that they
> have not been subjected to community review? It seems like the
> kind of thing that is of extreme relevance to the reader.

Because the statement "this has not been subjected to community
review" is often factually incorrect and because there are
multiple communities out there.  Some of these documents are
actually more intensively reviewed, by more experts, than some
things the IETF puts on the standards track.

If the IESG were inclined to quiz the RFC Editor as to what
review had occurred and then jointly identify each document,
including IETF Stream documents, with the precise type of review
that had occurred, we would be having a different discussion.
Headers and Boilerplates provides for some of that type of
annotation without requiring any IESG notes.

Alternately, if the IESG wanted to subject every Independent
Submission document to IETF Last Call, review the results of
that Last Call, and on that basis, sometimes generate a note and
subject it to IETF Last Call, I'd have no problem at all
introducing a section into Independent Submission Track RFCs
containing the IETF's opinion of the document, identified as
such.  For lots of good reasons, I don't expect that to happen
and do not consider vague text that may be false (e.g., claiming
that no review within the IETF community occurred when, in fact,
it might have) to be helpful in this regard.  I also believe
that having the IESG tell lies that can easily be tested and
exposed as such does not contribute positively to the reputation
of the IETF.

    john

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 31 Aug 2009 11:40:47 -0700

Joel M. Halpern wrote:
> If every document needs this marking, ...

If this line of discussion needs to happen, it needs to happen on a separate
thread, because I believe it has nothing to do with the current text, proposal, 
or concern.

As noted, it is opening a very old -- and I believe very different -- basic concern.

The current question is about IESG Notes.  We ought to restrict postings on this 
thread to that question.

d/

-- 

   Dave Crocker

---

From: Jari Arkko <[email-masked]>
Date: Mon, 31 Aug 2009 21:55:29 +0300

Dave,

> The current question is about IESG Notes.  We ought to restrict 
> postings on this thread to that question.

Yes.

As always, before a draft is actually approved we appreciate getting all 
kinds of feedback on it. Particularly if there's a serious problem 
somewhere. Of course, when a Last Call period is over, we do not re-open 
a document lightly even if it hasn't been approved yet.

However, in this case: if you have a general comment on 3932bis, please 
post to the Last Call thread. If you want to answer my specific question 
about the optional/mandatory nature of the IESG note, please respond to 
this thread. My current plan is NOT to reopen other aspects of the 
document, though I understand that some of them may have to be discussed 
to provide context for the specific question.

Jari

---

From: Adam Roach <[email-masked]>
Date: Mon, 31 Aug 2009 14:08:59 -0500

Jari Arkko wrote:
> However, in this case: if you have a general comment on 3932bis, 
> please post to the Last Call thread. If you want to answer my specific 
> question about the optional/mandatory nature of the IESG note, please 
> respond to this thread.

So, to be clear, the question you have raised has to do with the 
difference between:

    "The IESG may choose to add an IESG note to an Independent
    Submission..."

and:

    "The IESG may choose to request the addition of an IESG note to an
    Independent Submission..."

Right? This has nothing to do with the text:

    "In exceptional cases, when the relationship of the document to the
    IETF standards process might be unclear..." ?

/a

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 31 Aug 2009 15:49:57 -0400

+1 to Dave's suggestion below regarding the name of the draft, as well
as Joel's and John's responses to Jari's original question (i.e.,
retain existing practice regarding IESG notes).

Cheers,
Andy

On Mon, Aug 31, 2009 at 12:27 PM, Dave CROCKER<[email-masked]> wrote:
>
>
> Joel M. Halpern wrote:
>>
>>    The documented rules and practice has long been that with regard to
>> Independent Submissions the IESG notes are a request / recommendation to the
>> RFC Editor (soon to be ISE), not a statement of what will be included in the
>> result.
>
> ...
>>
>> text and its inherent tone, I would strongly prefer that IESG notes be an
>> exception.
>
> ...
>>
>> Thus, I strongly prefer (a).   I prefer that such notes be rare, and that
>> they remain recommendations to the ISE.
>
>
> +1.
>
> IETF/IESG and these other RFC streams, if the title of this draft were
> changed from "Handling of" to "Assisting with".
>
> d/

---

From: SM <[email-masked]>
Date: Mon, 31 Aug 2009 13:24:12 -0700

Hi Jari,
At 06:29 31-08-2009, Jari Arkko wrote:
>IESG note is just a recommendation to the RFC Editor or (b) 
>something that is always applied to the published RFC. Please reply 
>before the next IESG meeting on September 10. Some e-mails on this 
>topic have already been sent in the Last Call thread -- I have seen 
>those and there is no need to resend.

I prefer option (a); the IESG note is just a recommendation to the RFC Editor.

If the IESG wants the IESG Note to always be applied, it is 
determining the RFC Editor policy and that's the role of the IAB 
according to Section 5.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2009 10:33:52 -0400

--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
<[email-masked]> wrote:

> And now back to the input that I wanted to hear. I would like
> to get a sense from the list whether you prefer (a) that any
> exceptional IESG note is just a recommendation to the RFC
> Editor or (b) something that is always applied to the
> published RFC. Please reply before the next IESG meeting on
> September 10. Some e-mails on this topic have already been
> sent in the Last Call thread -- I have seen those and there is
> no need to resend.

Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.

    regards,
      john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Sep 2009 11:14:55 +1200

> +1 , including the "IETF consensus call" part.

I don't understand how IETF consensus is relevant to a non-IETF document.

In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.

     Brian

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Aug 2009 15:49:55 -0400

Joel,

I agree that IESG notes should be rare, but primarily because 
independent stream submissions should be rare :-).

Long ago, when I served on the IAB, we grappled with this problem, 
and failed to find a good solution. Despite what we say about RFC 
status and origin markings, the public sees RFCs as carrying the 
imprimatur of the IETF (not just that of the RFC Editor). When Jon 
Postel was the RFC editor, we were pretty comfortable with his 
judgement on these matters, this was less of an issue. However, time 
have changed and I would be happy to see inclusion of an IESG note be 
mandatory, contrary to historical practice.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Aug 2009 20:14:53 -0500

On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:

>>> I think it would be okay to have the note go through an IETF  
>>> consensus
>>> call.
>>>
>>

Can't the IETF can have a consensus that a non-IETF document relates  
to other IETF work in some way?

> inclusion of an IESG note can only be a request.

How would you expect the RFC editor to evaluate such a request? Under  
what circumstances would it be reasonable to refuse to include it?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Sep 2009 13:38:17 +1200

On 2009-09-01 13:14, Ben Campbell wrote:
> Can't the IETF can have a consensus that a non-IETF document relates to
> other IETF work in some way?

Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.

> what circumstances would it be reasonable to refuse to include it?

Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the IESG was
showing unreasonable bias.

    Brian

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Aug 2009 20:51:52 -0500

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:

[...]

> and I didn't think Jari was reopening that aspect.

Ah, sorry, I was agreeing with Brian Rosen statement that  a concensus  
call was okay. I didn't mean (and I doubt he did, but he can speak for  
himself) that I think we _needed_ one, only that if that were the only  
way we could make an IESG request "binding", then it was okay. If we  
feel we can trust the IESG on this, I'm okay with it :-)

> showing unreasonable bias.

I assume an ISE could also who bias.

It seems to me this all converges on deciding who has to appeal in a  
dispute.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 22:04:02 -0400

Making the IESG note mandatory, even if that required IETF agreement, 
would essentially give the IETf veto over the Independent stream.  The 
IESG would simply propose a note so extreme that no author would accept 
it on their document.  Given that I have seen proposed notes almost that 
bad in the past, I see no reason to believe it will not happen in the 
future.

Unless we wish to gut the Independent Stream of its right and important 
role of providing critical review of ongoing ideas, I would strongly 
recommend that the IAB not accept any procedure by which this would occur.

Remember, the IETF did not create the Independent Stream.  It arguably 
predates the existence of standards track documents.

Yours,
Joel

---

From: Ben Campbell <[email-masked]>
Date: Mon, 31 Aug 2009 21:07:11 -0500

On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:

> Making the IESG note mandatory, even if that required IETF  
> agreement, would essentially give the IETf veto over the Independent  
> stream.  The IESG would simply propose a note so extreme that no  
> author would accept it on their document.  Given that I have seen  
> proposed notes almost that bad in the past, I see no reason to  
> believe it will not happen in the future.
>
> Unless we wish to gut the Independent Stream of its right and  
> important role of providing critical review of ongoing ideas, I  
> would strongly recommend that the IAB not accept any procedure by  
> which this would occur.
>
> Remember, the IETF did not create the Independent Stream.  It  
> arguably predates the existence of standards track documents.
>

So can the mandate be scoped? It seems like a little word smithing  
could distinguish between "notes to clarify relationship with  
standards work" vs "commentary on the quality of the work".

>> Ah, sorry, I was agreeing with Brian Rosen statement that  a  
>> concensus call was okay. I didn't mean (and I doubt he did, but he  
>> can speak for himself) that I think we _needed_ one, only that if  
>> that were the only way we could make an IESG request "binding",  
>> then it was okay. If we feel we can trust the IESG on this, I'm  
>> okay with it :-)
>>>>
>>>>>
>> It seems to me this all converges on deciding who has to appeal in  
>> a dispute.
>>>
>>>   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 22:18:45 -0400

The scope already says that the IESG is only supposed to comment on the 
relationship to existing work.  When the comments are on that topic, 
there has rarely been an issue.  (The one related difficulty is when the 
IESG has asked for reasonable delays, to let a working group get its 
product out, and then the WG has taken much longer than expected to 
deliver.)
However, even then the editor has needed to edit the words provided.  Of 
course, such editing has to be negotiated with the IESG.  (The edit can 
edit, but he can't put words in someone elses mouth.)

Part of the problem I face is that there is significant evidence that 
the IESG has unintentionally produced very biased and inappropriate 
text.  The ISE (RSE) needs to have a strong position from which to 
discuss such things.

I will grant that an unreasonable ISE can do unreasonable things.
There is no history of difficulties in the converse.

If the ISE / RSE is unreasonable, the IAB will slap the editor and say 
"stop doing that."  There is no equivalent process if we reverse the 
structure.

Yours,
Joel M. Halpern

Ben Campbell wrote:
>> IESG would simply propose a note so extreme that no author would 
>> accept it on their document.  Given that I have seen proposed notes 
>> almost that bad in the past, I see no reason to believe it will not 
>> happen in the future.
>>
>> important role of providing critical review of ongoing ideas, I would 
>> strongly recommend that the IAB not accept any procedure by which this 
>> would occur.
>>
> So can the mandate be scoped? It seems like a little word smithing could 
> distinguish between "notes to clarify relationship with standards work" 
> vs "commentary on the quality of the work".
> 
>> Yours,
>> Joel
>>
>> Ben Campbell wrote:
>>> that were the only way we could make an IESG request "binding", then 
>>> it was okay. If we feel we can trust the IESG on this, I'm okay with 
>>> it :-)
>>>>>
>>>>>>