Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Sep 2009 10:34:56 +0300

Hi,

On 2009-8-31, at 18:34, Adam Roach wrote:
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.

I agree with you. This is exactly why I had originally proposed to  
stick the words "NOT AN INTERNET STANDARD" into the top left corner on  
the first page (where it currently says "Network Working Group") for  
all non-standards-track documents in all streams.

That proposal got shot down with the (paraphrased) argument "we should  
label RFCs with what they are rather with what they are not." I still  
disagree with this, because the #1 question what looking at any RFC  
should be "is this an Internet standard or not?"

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Sep 2009 10:37:00 +0300

On 2009-8-31, at 19:24, Joel M. Halpern wrote:
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."

FWIW, this was exactly what I proposed a while ago. The current way we  
label RFCs requires folks to understand the intricacies of the  
different streams. Few in the broader industry do.

Lars

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 1 Sep 2009 12:06:10 +0200

On Aug 31, 2009, at 3:29 PM, Jari Arkko 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.

I am happy to see the document being reverted so that an IESG note is  
exceptional.

Over the last years I've started to appreciate the fact that the RFC  
Series is not exclusively an IETF series. On the other hand I am  
sensitive to the argument that most consumers of RFCs do not see the  
fine distinction between standards track and non-standards track RFCs,  
let alone the difference between non-standards track from various  
streams. Headers and Boilerplates tried to address that and hopefully  
helps to clarify the fact that not every RFC is an IETF Standards  
Track document.

However, the whole RFC streams framework has been build with complete  
independence of the various stream in mind. In my opinion that makes  
sense. The IAB should not be able to force notes on IETF stream  
documents, the IRTF should not be able to put them on IAB stream  
documents, and the IESG should not be able to force them on IRTF, IAB  
and Independent documents. In other words it is not clear to me why  
the combination IESG and the Independent stream should have a special  
status. And, as other mentioned, deciding about that special status is  
not a matter that rests solely with the IESG/IETF stream.

I do think that in essence this is a fairly theoretical discussion. I  
believe that in general notes from the IESG will have merit and  
recommendations will in general be followed, specifically since they  
are likely to be exceptional. In the case that the judgement, by the  
IESG and ISE, of merit conflicts, there is a procedure in RFC 5620.

I'm for (a).

--Olaf (no hats)

________________________________________________________

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 Sep 2009 19:11:22 +0700

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

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

Definitely (a) - the reasons for this have already been made by many
others and I won't repeat them.

But, I'd also change the target of the recommendation - the IESG shouldn't
be asking or instructing the editor (whichever form of editor, RFC or ISE
or ...) in any way, rather they should be suggesting to the author of a
document that it would likely be more acceptable if it included some
extra particular text.

The editor would then, of course, take the author's response to that request
into account when deciding whether or not to publish the author's document.

Lastly, as has been stated already, but this time I will restate it for
emphasis, the IESG should not be making any kind of technical review of
independent submissions - the reason the review was even permitted (remember
previously independent submissions went directly to the RFC editor who simply
published them, or declined) was to allow work that was submitted independently
but which was directly in the same area as IETF work to be merged, and
all considered together.    That is, the IESG is just supposed to determine
whether there is (or perhaps should be) a WG to work on the same topic, and
if so, invite the author to submit the document to that WG for further
review (and even possibly elevation into the standards track).

Beyond that, the IESG should be leaving independent submissions alone.

kre

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Sep 2009 16:37:31 +0300

Robert,

> the IESG should not be making any kind of technical review of
> independent submissions

Right, and we are not.

>  - the reason the review was even permitted ... was to allow work that was submitted independently
> all considered together.

That is indeed the primary goal of the 3932 and 3932bis. I.e., promote 
independent work, but allow a check in the exceptional case that it 
collides with IETF work.

Jari

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 Sep 2009 21:40:10 +0700

Date:        Tue, 01 Sep 2009 16:37:31 +0300
    From:        Jari Arkko <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right, and we are not.

That is very good to hear.   I haven't been watching much of recent
IETF happenings (last few years) so I explicitly make no comment about
anything that has happened recently.

In the past however, back when I was more involved, there were occasions
when that was certainly not the case - there were cases where the IESG
decided that a proposal (an independent submission) would really be bad for
the internet, and requested (and perhaps even published) notes with comments
along the lines of how insecure, unscalable, and generally horrid some
document was, and strongly advising the world to ignore it.

That's all technical discussion, and none of that should ever be a part
of an IESG note requested to be added to a doc.

Given that, what's left for an IESG note pretty much amounts to "this
does not represent IETF consensus" or "Readers should also see RFCxxxx
for an alternative solution" - neither of which are very likely to be
ignored by the editor - or in fact, by the doc author if requested of
him or her - so there should be no need for mandatory addition of notes,
just a request should be enough (ie: if one ever is refused, the chances
are really pretty good that it should never have been requested.)

One final note, none of this, of course, prevents anyone, including
IESG members, writing their own independent submission, criticising some
other proposal (in a different RFC) - such a thing could even be made
an IETF consensus doc if desired - that's all reasonable,but of course
takes more effort, and real considered and supported arguments, an IESG
note to the same effect is just the lazy way out, and should never be
used (and to repeat my opening comment, I am not claimimg that it has any
time recently, I simply have no idea.)

kre

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Sep 2009 09:34:15 -0400

--On Tuesday, September 01, 2009 16:37 +0300 Jari Arkko
<[email-masked]> wrote:

>>  - the reason the review was even permitted ... was to allow
>>  work that was submitted independently but which was directly
>> in the same area as IETF work to be merged, and all
>> considered together.
> 
> That is indeed the primary goal of the 3932 and 3932bis. I.e.,
> promote independent work, but allow a check in the exceptional
> case that it collides with IETF work.

And that is, again, the answer to the question you raised.  In
the context of Headers and Boilerplates, the stream is
identified.  Many will pay attention or learn to do so.  Others
will not, but, for them (regardless of their motivation), there
is no evidence that "notices" in obvious front-matter
boilerplate will be noticed either.

If members of the IESG have technical issues with a document,
let them raise them as interested, skilled, and persuasive
individuals as both the current and proposed revised versions of
3932, and your comment above indicate that they should.   If
they have major philosophical disagreements, let them write
critical commentary, with explanations and details, and see if
they can get them published as RFCs.  Independent of their
ability to use the IETF Track to self-publish, I have never, in
the history of the RFC Series, seen the RFC Editor turn down a
competently written and clear criticism of another document --
IMO, in the last decade or two, there have been far too few such
submissions.

Conversely, independent of technical substance, if the document
is not clear enough about what it is --from the text-- tell the
RFC Editor (ISE) and thereby promote a discussion with the
authors about changes to make the document more clear.  If the
ISE ignores that advice, we quite frankly have a more serious
problem.  But I've never, and I mean never, seen that happen.

To rephrase what others have said, attaching derogatory notes
without explanations or specific attribution is the act of lazy
people who either cannot or will not take responsibility for
making document-specific comments that can either be attributed
to those making them or that have been through enough process to
represent IETF consensus.

     john

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 2 Sep 2009 15:41:51 +0200

---- Original Message ----- 
From: "John C Klensin" <[email-masked]>
Sent: Monday, August 31, 2009 4:33 PM

> --On Monday, August 31, 2009 16:29 +0300 Jari Arkko
> > I would like to get some further input from the community on
> > this draft.
> >...
> > 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.
> 

a) is my preference.

I am not persuaded by references to history, that the RFC Editor
function came first - cuckoos do take over nests (not that the
IETF is a cuckoo:-)

I do think it is a question of checks and balances, that being able
to submit and have reviewed an RFC, independently of the views
of the current IESG, is a valuable outlet for ideas and not one I 
want to see compromised.

John, below, outlines an appeal mechanism which allows the IESG
to take the issue to the IAB should it consider that justified and, 
assuming you agree that that is possible, then I see no case for 
anything other than a)

Tom Petch

> 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
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Sep 2009 12:38:40 -0400

Russ, I think that it is absolutely critical that the IETF be able to
attach a note to an RFC and that this note not simply be a
recommendation.

We can believe all we want that the IETF stream is just one stream and
that all other streams are independent.  However, the RFC process is
very tightly tied to the IETF, and I think it is reasonable for the
IESG to be able to raise a note in an exceptional circumstance.

I believe that this serves as an important check on the independent
stream, just as the independent stream is supposed to serve as an
important check on the IETF stream.

Part of my thinking is motivated by my belief that the IETF has more
structures in place and a broader community of people reviewing its
work than the independent stream.  I fully understand that there are
people who are involved/interested in the independent stream who are
not involved in the IETF.  I believe that independent+ietf is a
broader community than IETF alone.  (We assume that it is a
significantly broader community; I've never been given data to back up
that assumption, but I'm happy to hold it for the moment.)  However I
doubt that community is sufficiently broader that it should be able to
overrule the IETF.  Even if the community was sufficiently broader,
I'm still not sure that I would be comfortable with it being able to
overrule the IETF of a comment that the IETF wanted to place on an
independent stream document.

However, the IESG is not the IETF.  I'd personally be happy to ignore
that and assume it would all work out.  I'd also be happy with a
mechanism where the IESG could propose a note, and the RFC editor had
the option of accepting the note or asking the IESG to last-call its
note within the IETF community.

I would not consider it acceptable if the note were purely advisory.

---

From: Russ Housley <[email-masked]>
Date: Wed, 02 Sep 2009 17:23:27 -0400

I'd like to keep this discussion focused on the question that Jari 
asked.  While changes to the Independent Stream can be discussed, 
that seems like rfc4846bis, not this document ...

Several people have said that the RFC Editor already has the 
authority we are discussing here.  Sadly, it is not that simple.  The 
words cited below from RFC 3932 cloud this issue.  I think they 
conflict with the words in the RFCs cited by John.

RFC 3932 says:

    The IESG may return five different responses, any of which may be
    accompanied by an IESG note to be put on the document if the RFC
    Editor wishes to publish.

I think that "... to be put on the document if the RFC Editor wishes 
to publish" is the heart of the matter.  RFC 3932 leaves the RFC 
Editor with the final say on publication, but if the document is 
published, the note must be included.

Sam and Pasi have already pointed out that the RFC Editor can appeal 
the action taken by the IESG if they think the note is off base.  In 
practice, the RFC Editor has asked the IESG to reconsider the text of 
one note, and the IESG has done so.  There have not been any appeals 
on this topic since the publication of RFC 3932.

The rfc3932bis-08 text provides greater flexibility to the RFC 
Editor, making the IESG note a recommendation to the RFC Editor.  The 
is the flexibility that several people have claimed the RFC Editor 
has had all along based on other documents.

Please, let's try to answer this one question on this thread: When 
the IESG performs review of an Independent stream or IRTF stream 
document and provides an IESG Note, does the RFC Editor have the 
authority (without a request for reconsideration or an appeal) to 
publish the document without the IESG Note?

Russ

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Sep 2009 18:40:49 -0700

Sam Hartman wrote:
> Russ, I think that it is absolutely critical ...

Sam,

> However, the IESG is not the IETF. 

This is the single-most important statement in your note.

"Absolutely critical" is strong language, but is not warranted by 20 years of 
experience or any other empirical basis.  We need to be very careful not to 
confuse mathematical possibility with operational reality and we need to be 
careful to consider real costs, along with theoretical benefits.

The RFC Editor is also part of the IETF, with plenty of its own accountability, 
and it has established a history of highly professional and responsible 
performance, including over the last 10 years, while under "new" management.

The IESG is not, and must not be, the sole repository for responsible 
decision-making in the IETF, yet that really seems to be at the core of your view.

There is no legitimate reason to allow the IESG to mandate language in an 
Independent RFC, and there is very good reason /not/ to allow it to.

For example, it then wouldn't be Independent...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Richard Barnes <[email-masked]>
Date: Wed, 02 Sep 2009 23:31:17 -0400

Being a relatively short-term IETF participant, I lack the history that 
many on this list have, but since Jari asked for comments, I'll provide 
some.

Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and 
others that it makes sense to have IESG notes be mandatory for the ISE 
to include in independent stream RFCs.

Stated at more length:

What is clearly going on here is that our branding is out of sync with 
the expectations of our customers.  Whatever their historical meaning, 
RFCs are now interpreted by the broad community as documents that have 
the been reviewed and approved, to a greater or lesser degree, by the 
Internet community.  I think we all agree that documents that go through 
the IETF or the IAB can more or less legitimately claim that imprimatur.

Independent submissions clearly cannot.  Given that, it's not clear to 
me why the independent stream exists at all, other than for historical 
reasons.

Given that the abolition of the independent stream doesn't seem to be an 
option at this point, the next best thing to do is to require that 
independent-stream RFCs alert the reader to two things:
1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are

Clearly the first point is an issue for Headers and Boilerplates.  The 
second point is represented in the current process by IESG notes; if the 
Internet community has concerns about a document, they can be included 
in the document as an IESG note.  Given that the IESG is selected 
through a community process, I'm comfortable with this delegation, 
though requiring IETF consensus would clearly add some assurance.

The other implication of the above paragraph is that the *absence* of an 
IESG note indicates to the reader that the community has no serious 
concerns, which means that enabling the ISE to reject IESG notes 
effectively enables the ISE to speak on behalf of the community.  Given 
the choice, I would prefer the IESG to speak for me than the ISE.

So I agree with Jari's option (b), that IESG notes should be something 
that is always applied to the published RFC.

--Richard

Jari Arkko wrote:
> 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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Sep 2009 00:20:54 -0400

In fact, I do not think the presence or absence of a note means what you 
describe.

First, remember the Independent Submission do get reviewed.  They do not 
get IETF review.  But they do get technical review by senior technical 
participants in this community.  This review can be thought of, as 
another note pointed out, as being comparable to the peer review 
required for scholarly journals.

Secondly, given that one of the points of the stream is to provide a 
mechanism for informed critique of our work, it is unsurprising that the 
IESG has objected to such critiques.

Third, it should be remembered that the IESG review being discussed is 
not a technical review.  It is a review for the relationship between 
this work and the IETF work.  If the IESG finds that there is a relevant 
relationship, and provides a reasonable note saying so, then the ISE is 
going to publish it.  (There may be negotiation about the wording, but 
the editors responsibility to be factually accurate means that such 
accurate notes will be published.)  If IESG members in reading the 
document find technical problems, then they should tell the ISE, just 
the way any other reviewer would.

Next, given that the review is not technical, and given that the review 
is done by a small number of people, I would not want a reader to draw 
conclusions about technical competence based on the presence or absence 
of an IESG note.  Such conclusions should be based on reading the document.

And let's be careful about asserting that IESG review is an assurance of 
quality.  There have been plenty of marginal documents that the IESG has 
approved over the years.   Sometimes they approved them for very good 
reasons.  Note that even 15 years ago the IESG was under interesting 
publication pressures some of the time.  I am sure it still is.

If you want to abolish the Independent Stream, then we can have a 
discussion (separately from this one) about who would get to do that, 
and whether that would mean that the IETF would have to find a different 
outlet, or the Independent Stream.  The mix of history, practice, and 
branding would make for a very confusing situation.  Personally, I think 
the Independent Stream is valuable.  (That's why I help review them.) 
So I do not want that stream or its independence weakened.

Also, remember that there are actually 4 streams.  I presume that no one 
is trying to suggest that the IESG should get to put IESG warning notes 
on IAB documents or IRTF documents?  Yet IRTF documents are actually 
sometimes less reviewed than Independent Stream documents.  It is not 
uncommon for an IRTF Working group to produce multiple reports when the 
group can not come to agreement.  (Note, I do not think that the degree 
of review correlates with the degree of quality.  That is a further 
confusion about these notes.)

Yours,
Joel M. Halpern

Richard Barnes 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: SM <[email-masked]>
Date: Thu, 03 Sep 2009 02:09:51 -0700

Hi Richard,
At 20:31 02-09-2009, Richard Barnes wrote:
>Stated at more length:
>
>What is clearly going on here is that our branding is out of sync 
>with the expectations of our customers.  Whatever their historical 
>meaning, RFCs are now interpreted by the broad community as 
>documents that have the been reviewed and approved, to a greater or 
>lesser degree, by the Internet community.  I think we all agree that 
>documents that go through the IETF or the IAB can more or less 
>legitimately claim that imprimatur.

Some people interpret RFCs as Internet Standards even though the 
document contains "It does not specify an Internet standard of any 
kind." on the first page.  One of the differences between the IETF 
Stream and the Independent Stream is that the former is reviewed by 
the IETF Community.  The IETF Community is small part of the Internet 
community.  This discussion is about a specific type of IESG Note 
where the IESG is supposed to only check for conflicts between the 
work of the IETF and the documents submitted.  That sounds fairly 
simple.  This discussion highlights there may be divergent views even 
for simple questions.

>Independent submissions clearly cannot.  Given that, it's not clear 
>to me why the independent stream exists at all, other than for 
>historical reasons.

The Independent Stream offers you a path to publish your document if 
the IESG does not find it suitable for publication.  If you are using 
that path to bypass an IETF Working Group, the IESG Note under 
discussion comes into play.

Some people find the IETF path too expensive as it seems that you 
have to be an insider to get your document published.

The important point here is that you are offering a workable 
alternative to people to publish their work even though the IETF does 
not agree with the contents of the document, i.e. diverse views are 
not suppressed.  It's more than a check and balance.  Having this 
stream also allows the IETF to assess the effectiveness of its 
processes and document quality.  In other words, if it is faster to 
publish through the Independent Stream and the output of that stream 
is better, the IETF can find out whether there is a problem with its stream.

>Given that the abolition of the independent stream doesn't seem to 
>be an option at this point, the next best thing to do is to require 
>that independent-stream RFCs alert the reader to two things:
>Clearly the first point is an issue for Headers and 
>Boilerplates.  The second point is represented in the current 
>process by IESG notes; if the Internet community has concerns about 
>a document, they can be included in the document as an IESG 
>note.  Given that the IESG is selected through a community process, 
>I'm comfortable with this delegation, though requiring IETF 
>consensus would clearly add some assurance.

The second point is not represented in the current process by the 
IESG Note under discussion.  That note does not mean that the 
Internet community has concerns.  It means that it is the opinion of 
the IESG that the document fulfills one of the five conditions in Section 3.

>The other implication of the above paragraph is that the *absence* 
>of an IESG note indicates to the reader that the community has no 
>serious concerns, which means that enabling the ISE to reject IESG 
>notes effectively enables the ISE to speak on behalf of the 
>community.  Given the choice, I would prefer the IESG to speak for 
>me than the ISE.

The ISE is not speaking on behalf of the IETF Community.

I don't know whether you would agree to me as to whether the RFC 
Editor has been able to ensure the consistency of the RFC Series over 
the years.  I encourage you to read some of the notes from Bob Braden 
and the RFC Editor team about the RFC Editor.  Some of them may be 
historical in nature but they also spell out a constant line of 
thinking.  The decisions taken are not done lightly and they are 
still relevant after all these years.  Consistency also means that it 
is highly unlikely the RFC Editor will drop an IESG Note based on a whim.

>publish the document without the IESG Note?

It would be better to define the problem.  As I see it, the problem 
is that the RFC Editor might drop the IESG Note and publish the 
document as a RFC.  Once that is done, there is no way to revert 
back.  With the forthcoming changes to the RFC Editor, the IETF 
Community and/or the IESG are facing an unknown.  I suggest following 
John's proposal.  A formal notification from the ISE and delay in the 
publication gives the IESG the opportunity to take any action it deems fit.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 03 Sep 2009 09:17:51 -0700

Richard Barnes wrote:
> the expectations of our customers. 

One of the historical items of note is that this supposed problem has been
present for about 20 years.  In other words, nothing has changed.

For example, it prompted RFC 1796, "Not All RFCs are Standards" almost 15 years ago.

>   Whatever their historical meaning, 
> Internet community. 

To whatever extent it is true now, it's been true for decades and it hasn't 
caused any real-world problems that have been documented.

Let me repeat: we have no documentation that, to whatever extent there is 
confusion amongst RFC readers about the status of different RFCs, it causes 
meaningful problems.

Moreover, the core implication of your assessment is that we should shut down
the Independent Stream entirely. And indeed, you indicate that that would be 
your preference.

However, please note that you are creating a new distinction in this area of 
discussion:  "reviewed and approved by the Internet community" versus "IETF 
Standard".  Again, there is no evidence that the broader community understands 
the subtlety of that distinction, so perhaps we should really require that all 
RFCs be standards?

 >     I think we all agree that documents that go through

That's your real question.  And absent an understanding of its reason for being,
how is it possible to state a preference for how it should be handled?

On the other hand, your clear statement that you believe the stream should not 
exist substantiates the concern that allowing the IESG to mandate content of an 
Independent document effectively brings that stream under the control of the 
IESG.  So Independent won't be.

> 2. If the Internet community has any serious concerns, what they are

The IESG is not "The Internet Community".  It is a tiny group of folk, with the
usual array of expertise and biases.  Why should it be allowed to mandate the
content of documents that it has no involvement in and that are intended to be 
independent of IESG control.

> concerns, 

Really?  This presumes that folk would know to expect an IESG Note.  Given the 
other things we know they don't know about the RFC series, they aren't likely to 
know about this possibility.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Sep 2009 16:08:04 -0400

--On Wednesday, September 02, 2009 17:23 -0400 Russ Housley
<[email-masked]> wrote:

> I'd like to keep this discussion focused on the question that
> Jari asked.  While changes to the Independent Stream can be
> discussed, that seems like rfc4846bis, not this document ...
> 
> authority we are discussing here.  Sadly, it is not that
> simple.  The words cited below from RFC 3932 cloud this issue.
> I think they conflict with the words in the RFCs cited by John.

They do indeed and I'm not sure how helpful it is to spend a lot
of time exploring this.  I'd much rather just get 3932bis
approved and move on.   But...

> I think that "... to be put on the document if the RFC Editor
> wishes to publish" is the heart of the matter.  RFC 3932
> leaves the RFC Editor with the final say on publication, but
> if the document is published, the note must be included.

The question isn't about what 3932 says (about which we agree)
but from where the IESG derives the authority to say such
things.  Nothing in 2026 or any other defining documents gives
the IESG the authority to make such demands on the RFC Editor.
Nothing that I can find even gives an IETF Community consensus
process the ability to impose such a requirement.

> Sam and Pasi have already pointed out that the RFC Editor can
> appeal the action taken by the IESG if they think the note is
> off base.  In practice, the RFC Editor has asked the IESG to
> reconsider the text of one note, and the IESG has done so.

> There have not been any appeals on this topic since the
> publication of RFC 3932.

Some of us considered appealing the language in 3932 discussed
above when it was under review and decided not to because of the
degree to which 3932, in toto, seemed like an improvement over
its predecessor and because we didn't dream at the time that the
sample notes would be interpreted as rigid and prescriptive
text.   Similarly, while there were a few specific notes on a a
few documents that I think the RFC Editor should have appealed,
I don't think it is reasonable to infer "acceptance of the
IESG's authority" from "no appeals".

To use a deliberately silly and unlikely example, the RFC Editor
(and the IAB) have accepted the notion that the IESG can take an
IETF-track document and insist that it be published and
published without alteration.  Let's suppose the IESG put a
document over that transom that claimed BCP status, said
"publish and publish as-is", and whose content said "the earth
is flat and the moon is made of green cheese".  I assume it
would be published as an RFC and entered into the index as a
BCP.   I assume that it wouldn't have much effect on the shape
of the earth or composition of the moon.  The IESG's approving a
document that says "if we supply a 'note', the RFC Editor can
either publish with that note or not publish at all" should not
be considered as much more effective.

Whatever authority 3932 has in this area derives from the very
general IAB statement that makes up Section 6.   But the IAB has
subsequently (as that paragraph contemplates) made its position
on this subject very clear in the stream-defining RFC 4844 and
the provisions of RFC 4846.  As one of Olaf's notes indicated,
that IAB conclusion didn't favor mandatory notes across streams.

> Please, let's try to answer this one question on this thread:
> When the IESG performs review of an Independent stream or IRTF
> stream document and provides an IESG Note, does the RFC Editor
> have the authority (without a request for reconsideration or
> an appeal) to publish the document without the IESG Note?

It should be clear from the above that my answer is "yes, the
RFC Editor does... and always has, regardless of what 3932 says
or appears to say, and that nothing the IESG does in terms of
document-writing or approval can change that".   Given its
responsibility to supervise the RFC Editor function, a decision
by the IAB might, of course, be another matter.

   john

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 3 Sep 2009 19:40:10 -0400

On Mon, Aug 31, 2009 at 2:29 PM, Adam Roach<[email-masked]> wrote:
> Joel M. Halpern wrote:
>...
>> 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 believe that the Independent Stream should continue to exist and
that IESG notes should be recommendations, rather than mandatory.

Here are some of RFCs of which I was an author that were Independent
Stream submissions, with notes:

RFC1898 CyberCash Credit Card Protocol Version 0.8
     This RFC documents a propriety protocol, making the protocol
public. The document internally makes it pretty clear that it came
from CyberCash, Inc., but I wouldn't say there is a "prominent note"
to that effect. It contains statements that could easily be
categorized as marketing. One effect of publishing this RFC was to
preclude later patent claims for the ideas it contained.

RFC2706 ECML v1: Field Names for E-Commerce
     This one has an IESG note commenting on its source and noting
technical deficiencies in internationalization. I'm not sure what the
policy was at the time but the IESG was, in effect, doing technical
reviews of such submissions. As an author, I had no objection to the
IESG note as I basically agreed with it. It was obsoleted by:

RFC 3106 ECML v1.1: Field Specifications for E-Commerce
     I believe this was also an independent submission. It's IESG note
points out the non-IETF source for these documents and that this work
was moving into the IETF where an IETF working group was working on a
v2. This v2 was later published as RFC 4112 as a Proposed Standard.
Thus, in this case, the independent stream provided a convenient means
to provide some continuity in the publication of work which was
transitioning into the IETF.

RFC 4144 How to Gain Prominence and Influence in Standards Organizations
     I submitted this to the IESG, it was assigned to the IETF Chair
who, after reviewing, decided that it was inappropriate for anything
but the Independent Submission stream. See:
https://datatracker.ietf.org/idtracker/draft-eastlake-prominence/comment/28295/

Hopefully the above examples give some idea of the range of items
published in the Independent Stream.

Thanks,
Donald

> 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: "Doug Ewell" <[email-masked]>
Date: Sat, 5 Sep 2009 10:25:41 -0600

"SM" <sm at resistor dot net> wrote:

> kind."

The document also says "Request for Comments," which is not even 
remotely true -- it represents the end of a long reviewing and 
commenting and evaluating process, not the beginning -- and it also says 
"Network Working Group," when there are over 100 active WGs but none 
with that name.

The more boilerplate takes over a document, the less readers will be 
inclined to interpret any of it literally.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 8 Sep 2009 16:36:55 +0200

On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:

> I believe Sam's suggestion offers a good compromise position: if the  
> IESG
> and RFC Editor do not come to an agreement, we should last call the  
> proposed
> IESG Note and let the community determine whether (1) this is an  
> exceptional
> case meriting a note and (2) if the text accurately clarifies the
> relationship.

Which community, The IETF community or the wider RFC community? And  
who calls the consensus?

--Olaf

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Sep 2009 12:02:04 -0400

--On Tuesday, September 08, 2009 16:36 +0200 Olaf Kolkman
<[email-masked]> wrote:
 
>> I believe Sam's suggestion offers a good compromise position:
>> if the   IESG
>> and RFC Editor do not come to an agreement, we should last
>> call the   proposed
>> IESG Note and let the community determine whether (1) this is
>> an   exceptional
>> case meriting a note and (2) if the text accurately clarifies
>> the relationship.
> 
> 
> Which community, The IETF community or the wider RFC
> community? And who calls the consensus?

Also, please remember, again, that the IESG _always_ has the
right and opportunity to publish a dissent as a separate RFC in
the IETF Track.  If that dissent is wildly out of line with the
wishes of the IETF community, the IETF community presumably has
ways to deal with that.  Anything sufficiently controversial to
justify the procedure above almost certainly justifies that
treatment because a separate RFC can document reasoning and
context, while any plausible note (and all such notes so far,
including the texts specified in 3932) merely provide a
statement of conclusions.

The main argument I've heard against that approach is that the
IESG doesn't have the time.  But, if it doesn't, then a full
community review as described above, with the inevitable
community fine-tuning of text, is certainly going to equally
time-consuming.  The issue justifying comment is either
important or it is not, and allowing the IESG to impose a note
by a cryptic comment (whether intentionally so or not) in
minutes and/or the tracker doesn't serve either the community
nor the separation of streams well.

Perhaps we should be discussing supplementing "Obsoletes" and
"Updates" in RFC headers and the index with "Dissents from",
"Heaps abuse upon", and/or "Ridicules" to make the intended
relationships among document more clear, but...

    john

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Sep 2009 12:09:17 -0400

Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to do the
consensus call, that's fine with me.  If we do that we'd need to make
it clear how this interacts with the IETF appeals process.  I'm not
thrilled with the appeals process starting with the IAB and only going
to the ISOC BOT in case there is no adequate process (6.5.3 in RFC
2026).  However I could live with that.  I suspect this may be one of
those cases where we know we've gotten a good compromise because no
one is happy with it.

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 8 Sep 2009 10:13:17 -0400

In my opinion, 3932bis is internally inconsistent about IESG notes.  This
document expressly directs the IESG to reserve IESG notes for exceptional
cases, but then leaves the decision on whether the note should be included
to the RFC Editor:
                   
>    In exceptional cases, when the relationship of the document to the IETF
>    standards process might be unclear, the IESG may request that the RFC
>    Editor include 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.

Personally, I think that the relationship is unclear in many cases, but it
is all a question of degree.  I interpret this text as directing the IESG to
reserve such notes for cases where serious conflicts exist and it is
particularly important to clarify the relationship and identify the
documents that represent community consensus.  In such a case, I would not
want to see the RFC Editor ignore the request or modify the note without
IESG agreement.  The current text of 3932bis seems to permit either.

I believe Sam's suggestion offers a good compromise position: if the IESG
and RFC Editor do not come to an agreement, we should last call the proposed
IESG Note and let the community determine whether (1) this is an exceptional
case meriting a note and (2) if the text accurately clarifies the
relationship.

Tim Polk

On 9/2/09 12:38 PM, "Sam Hartman" <[email-masked]> wrote:
> I'd also be happy with a

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 8 Sep 2009 11:17:17 -0400

Olaf,

I meant the IETF community.  Since the note would exist to clarify the
relationship with documents developed by the IETF community,  that seems the
right one to evaluate whether a note is needed.

As to who calls the consensus, that is a tricky one.  How about the IAB
chair?

Tim

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 08 Sep 2009 10:29:39 -0700

> case meriting a note and (2) if the text accurately clarifies the

On its face, this is certainly a reasonable path to follow.  However it has 
three practical problems.

One is effort and delay.  Adding more layers of decision-making and negotiation 
imposes non-trivial cost. The more barriers we place in the way of independent 
submission, the less it will get used. Worse, that's a stated goal for some folk.

The second is that it has become nearly impossible to find anything that looks 
like classic "rough consensus" on the IETF list.  The diversity of 
understanding, commitment and goals of participants on the IETF list has become 
far too diverse.  So as a mechanism for discerning how to resolve an impasse, it 
isn't likely to be very helpful.

The third is that it creates a negative incentive for the RFC Editor to act as 
an independent agency.  When it presses a point and finds a wall of hassle to 
deal with, this has a chilling effect on its likelihood of pressing.  They come 
to see such matters of principle as not worth the effort.

d/
-- 

   Dave Crocker

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 9 Sep 2009 09:11:00 +0200

On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:

> it clear how this interacts with the IETF appeals process.

Sam,

the underlying point of my question is that the streams are  
independent and that the IETF (stream) has no say about the other  
streams. IETF consensus or not. I am not even sure the IAB has a roll  
in calling the consensus.

But there is a nugget in the introduction of a last call: I think that  
the ISE has a very hard time explaining to the RSE that a note that  
has backing of IESG consensus will not be published. (I am assuming  
the use of the appeal procedure as described in RFC5620, which I think  
is appropriate for a difference of opinion between RFC entities such  
as the ISE and the IESG). If in such conflict the RSE would choose  
sides of the ISE then I am pretty sure something is severely broken  
and the appearance of a note is the least of our problems.

So in other words what I am saying is don't invent process but follow  
existing pieces:

- put a note in front of the ISE
o if the ISE pushes back
- last call the note in the IETF, to make sure the IESG actually  
represents IETF consensus --whereby the consensus is called by the  
IESG following normal process and appeal--, and go back to the ISE  
telling that the note has IETF backing.
o if the ISE pushes back
- consider this a disagreement between stream entities and follow RFC  
5620 appeal process.
o if the RSE chooses sides with the ISE the note gets published but  
the IAB, the IESG, and the RSE have some serious talking to do because  
something is severely broken elsewhere than just the note. The RFC  
will most probably be published without the note but the IESG has the  
possibility to publish a "This RFC sucks for this reason RFC" while  
the real problems are being addressed

Obviously publication of the document should be delayed on request  
from the IESG while the above is sorted out in a timely manner.

-- Olaf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 07:17:50 -0400

>>>>> "Olaf" == Olaf Kolkman <[email-masked]> writes:

    Olaf> On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:

    >> that is last called.  Normally, the IESG judges IETF consensus.
    >> However, if it makes the IAB more comfortable for the IAB chair
    >> to do the consensus call, that's fine with me.  If we do that
    >> we'd need to make it clear how this interacts with the IETF
    >> appeals process.

    Olaf> Sam,

    Olaf> the underlying point of my question is that the streams are
    Olaf> independent and that the IETF (stream) has no say about the
    Olaf> other streams. IETF consensus or not. 

Right; I think I made it fairly clear in my reply to John Klensin that
I disagreed fairly strongly with that and argued why I believed that
the IETF needs a special role to attach a note to something.  No
discussion prior or since has changed my mind.

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Sep 2009 19:54:14 +0700

Date:        Wed, 09 Sep 2009 07:17:50 -0400
    From:        Sam Hartman <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right; I think I made it fairly clear in my reply to John Klensin that
  | I disagreed fairly strongly with that and argued why I believed that
  | the IETF needs a special role to attach a note to something.  No
  | discussion prior or since has changed my mind.

Ask yourself if you'd have the same opinion if the IETF was publishing
its output in IEEE Transactions on Networking (or any similar publication),
or even something like the NY Times.

Would you still expect the IESG to be able to tell the editor of that
publication what they are required to do?

Then note that this is exactly the same ralationship that the RFC
editor should have with the IETF.

In any case, if the editor is failing to perform adequately, the correct
response is to replace the editor - there is no rational consittuency here
in which to seek consensus (no matter who does the seeking) and no-one
rational to handle appeals, so I'm not in favour of John K's compromise
proposal.

Simply allow the editor the discretion to make his/her own decisions
(in this case, it will become the ISE with co-ordination from the RFC editor)
and then if they're failing (which mostly means, not getting things published, 
but might also mean sub-standad publications), then replace them with
someone who can do better.

Nothing more than that is needed.

kre

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 09:22:45 -0400

>>>>> "Robert" == Robert Elz <[email-masked]> writes:

    Robert> Then note that this is exactly the same ralationship that
    Robert> the RFC editor should have with the IETF.

I disagree for reasons I have previously stated.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 9 Sep 2009 09:50:07 -0400

Sam,

The burden of proof rests on those like you who wish to change the
independent stream from a respected independent publishing channel to
something subservient to the Area Directors, a change which seems
entirely gratuitous without any historically demonstrated need.

Donald

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Sep 2009 22:09:09 +0700

Date:        Wed, 9 Sep 2009 09:53:42 -0400
    From:        "Polk, William T." <[email-masked]>
    Message-ID:  <[email-masked]>

  | IMHO, the RFC series (as comprised by the four document streams) is not
  | similar to IEEE Transactions on Networking or the NY Times.  I am not sure
  | that there is really a close analog out there.

It is an independent publisher publishing material submitted to it - the
NY Times analogy isn't close, as they create much of their own material,
which neither IEEE Transactions, nor the RFC editor do (or not much of,
indexes and stuff like that excepted), but aside from that, there shouldn't
be a lot of difference.

  | The better question is, if IEEE was distributing the output of the IETF in
  | its series of standards publications

You're operating under the mistaken impression that the RFC series is
IETF standards - it isn't - some of he RFCs are IETF standards, others
are other IETF publications, and others have nothing to do with the IETF
at all.   It is just a document series that the IETF happens to use as
a place to publish its output.

If there was a document series and publisher that was exclusively for
IETF standards, then we wouldn't be publishing anything else there at all,
and the question of notes would be irrelevant - that would be closer to the
way IEEE and ISO standards are published - but that is not what the RFC
series is now, or ever has been.

  | And are we really helping anyone by not clarifying the relationship between
  | the document and other RFCs?  Shouldn't we provide this information as a
  | service to the reader?

Many times that is reasonable, probably, and no-one is suggesting that
the RFC editor always refuse to publish IESG notes (though some of us
don't believe the IESG should very often, if at all, request one) - the
question isn't what happens when an IESG note is appropriate, the question
is what happens when it isn't - and who gets to decide.

kre

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Sep 2009 08:32:14 -0700

> a place to publish its output.

This is the core point.  Some folk want to re-cast the RFC series as structly 
subservient to the IETF.  But that's not how it has operated for 40 years.  Yes, 
folks, 4 decades.

There is a fundamental difference between "having a strong relationship" versus 
"being subservient".

In order to make such a basic change, there needs to be a compelling statement 
of need for which there is strong community consensus.  None has yet been 
offered, except the same one that gets repeated every few years, for at least 20 
  years, namely that some folk don't understand the RFC series.  Sigh.  Yes, 
folks, this thread is the same as has been repeated many, many times, including 
the consistent lack of demonstrated damage from the current arrangement.

d/
-- 

   Dave Crocker

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 09 Sep 2009 09:07:21 -0700

Hi,

As it has been pointed out here often, the RFC series is more than just the
document numbering scheme for IETF standards.  However, if you attend a
marketing gathering, a random CS conference, a non-IETF standardization
meeting, or even the IETF plenary, a majority of people (probably a large
majority) would answer the question "what are RFCs" with "standards set by
the IETF", or something thereabouts.

This *perception* is important.  And changing it means changing the
*perception* of a large number of people, for very little value except
honoring a 40 year old institution.  That's not a value proposition I can
easily support.

If the IETF is *perceived* as the owner and/or sole contributor to the IETF
series, it should have influence up to veto power regarding the content of
that series, through its chosen management structure---that is, AFAIK and in
this case, the IESG.  Otherwise, it cannot stop the publication of documents
against its interest.

It's pretty clear now that the IESG is not going to get the tools I consider
required to influence the RFC editor, due to historical facts and the
independence of the RFC editor and its support functions.

Is it time that the IETF considers publishing its material elsewhere?

Regards,
Stephan

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Sep 2009 09:19:05 -0700

Stephan Wenger wrote:
> series, 

Stephen,

First, you lack empirical data to substantiate your assessment of the perception.

Second, you lack empirical data that it is causing a pragmatic problem.

That is what ought to be the lesson of having repeated this thread every few 
years for 20 years ought to be.

Make a change when you have a demonstrable, real and damaging problem, not just 
something you don't like.

d/
-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Sep 2009 12:36:45 -0400

> First, you lack empirical data to substantiate your assessment of the perception.

Well, Wikipedia (which IMO is primarily useful as a repository for
finding out what "everyone knows") has this first sentence in its
description of the RFC series:

> In computer network engineering, a Request for Comments (RFC) is a
> memorandum published by the Internet Engineering Task Force (IETF)
> describing methods, behaviors, research, or innovations applicable to
> the working of the Internet and Internet-connected systems.

The fourth link from Google in response to, "What is an RFC?" says

> RFC is an acronym for Request for Comments and official documents from
> the Internet Engineering Task Force (IETF) with an unlimited
> distribution.  RFC's are numbered in a series and are referred to by
> numbers.

So even if those pages go on to refine their statements, I don't think
it preposterous to suggest that people think "the RFC series" is "from
the IETF".

I am totally unwilling to have an opinion on whether anyone ought to
try to do anything about this, but I don't think we should pretend
that the world is otherwise than it is.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 09 Sep 2009 09:52:05 -0700

Hi Dave,

I agree with your second observation.  It may well be that the current RFC
editor model has not *yet* caused a pragmatic problem.

I stand to my first assessment, as originally formulated.

The main issue is: should the IETF be pro-active on these matters, or not.
For the IETF as an organization, I see no value beyond traditions in staying
with the RFC publication model.  (The marketing value of using the RFC
series is IMHO contradicted by the lack of control of the IETF over the RFC
series).  If there were indeed no value beyond traditions, why run any risk,
no matter how small?  Certainly there must be some risk in giving the RFC
editor, rather than the duly appointed IETF officials, the last say in
publishing documents that are perceived as IETF documents.

I could follow an argument that changing the publication mechanism is large
enough a pain to best avoid it, for the small pragmatic gains we may get.

Regards,
Stephan

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Sep 2009 10:34:02 -0700

Andrew Sullivan wrote:
> Well, Wikipedia 
...
...
> it preposterous to suggest that people think "the RFC series" is "from

Andrew (and Stephen),

Thank you for exploring the question of empirical data, as well as demonstrating 
how methodologically challenged discussion in the IETF tends to be, particularly 
with respect to anything involving or implying statistics...

The original comment was about universality of perception.  Particular examples 
were cited at the beginning of Stephen's note, but they morphed into a statement 
of universality by the end of it.

Your own note cited the first and fourth google listings but left out, for 
example, the second and third.  Based on that latter set, I could claim that 
"THE" perception is that the RFC series is "the working notes of the Internet 
research and development community" and "a formal mechanism used to describe 
communications standards for the Internet and systems (like USENET) that are 
closely tied to it."

That's quite a different characterization of the RFC series and besides being 
more accurate, it has the same empirical basis being put forth as "the" 
perception" of the series as what you are citing.

But, of course, this is all about the first of two challenges I offered and 
empirical data for the latter is what justifies considering a change.

Stephen just posted the view that we should be "proactive", but does not seem to 
understand that we missed that opportunity 20 years ago.  Whatever "problem" we 
need to anticipate has failed to materialize for two decades.

But the real crux of this debate is represented by the difference between my 
second challenge and Stephen's alternative challenge: "If there were indeed no 
value beyond traditions, why run any risk, no matter how small?"

First, it means that we need to be clearer about the intended benefit behind 
having the Independent stream.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)

Second, it misses the practical implication of making changes due to imagined 
risks, particularly since there is always an infinite set of them to choose from.

Third, it ignores the operations rule that all change is, itself, risk, and that 
therefore no change is justified unless there is a solid basis for expecting 
very, very substantial benefits.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)

d/
-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Sep 2009 14:20:26 -0400

On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote:

> for example, the second and third.  Based on that latter set, I could 
> claim that "THE" perception is that the RFC series is 

I am at the best of times uneasy with universal quantifiers, and
certainly when talking about THE belief of THE Internet, I feel pretty
uneasy.  Also, I haven't followed this discussion much, partly because
I fully agree with the observation that most of it has been hashed so
much, and warmed over so many times, that it's now turned into a form
of American breakfast potato.

But it doesn't seem to me to be doing favours to anyone to deny the
obvious point that there's at least a substantial community of people
who regard the label "RFC" as bespeaking "an IETF document" and also
"Internet standard".  Claiming that it's not true by pointing to
examples of careful and clueful definitions (one of which is
practically a sockpuppet for the IETF pages themselves) does not
clarify this matter.  Even organizations involved in the
administration of the Internet apparently rely on something "being an
RFC" as somehow implying an _imprimatur_ or at least _nihil obstat_
(if anyone wants evidence of that matter, I think the archives of
agreements found at ICANN will be instructive). 

Again, I wish to emphasise that this is completely distinct from the
question of whether anyone ought to do anything about the state of
affairs.  I refuse to take a position on that, or even consider it as
a topic for a conversation in which I'll be involved.  There are
enough windmills around without us throwing up new ones at which we
can tilt.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 9 Sep 2009 12:05:25 -0700

> enough windmills around without us throwing up new ones at which we

That's a shame. The standards world is looking for someone who can tilt at
the windmills that are the entrenched habits of our day. Who wants to be the
hero of that novel?

I'm being serious. I agree with you that there is much unhelpful confusion
about "RFCs".

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
3001 King Ranch Road, Ukiah, CA 95482
Cell: 707-478-8932

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Sullivan
Sent: Wednesday, September 09, 2009 11:20 AM
To: [email-masked]
Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature
of IESG notes

A

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Sep 2009 09:48:33 -0400

Olaf,

Let me suggest tuning this a bit, with the understanding that
what I'm about to suggest lies well within current procedures,
RFC 5620, etc.

--On Wednesday, September 09, 2009 09:11 +0200 Olaf Kolkman
<[email-masked]> wrote:

>...
> But there is a nugget in the introduction of a last call: I
> think that the ISE has a very hard time explaining to the RSE
> that a note that has backing of IESG consensus will not be
> published. (I am assuming the use of the appeal procedure as
> described in RFC5620, which I think is appropriate for a
> difference of opinion between RFC entities such as the ISE and
> the IESG). If in such conflict the RSE would choose sides of
> the ISE then I am pretty sure something is severely broken and
> the appearance of a note is the least of our problems.

I would not assume that unless you assume that there is some
part of the model that somehow prevents the IESG from getting
out of control.  If there is not, then, to be orderly, one has
to assume that it is fully as possible that the IESG (as the
IETF stream-approver) is out of control as it is that the ISE
(as the Independent Submission stream approver) is out of
control.

I also imagine that the IESG could, if so inclined, issue a Last
Call that would be so stated as to produce a confirming result,
especially if comments from those who do not believe that there
should be an Independent Stream were counted along with those
who actually understood the particular issues and confirmed the
importance of the note.  Also remember that the IESG does the
counting and, to refer back to an earlier comment on the list,
figures out what the consensus is even when it is not obvious.

The particular case I would be most concerned about would
involve a document that was highly critical of an IETF Standard,
but that was extremely clear that it was a critique, that
documented the disagreement in a balanced way, etc. -- in other
words, where there was a dissent from an IETF standards-track
document and no possibility of confusion with one.  I could
easily imagine the IESG disagreeing with such a document and
wanting to get the last word in with a "don't pay any attention
to this" note.  If they are permitted to do that, with or
without a claim of IETF consensus, then there is no Independent
Stream, only an "independent as long as documents are reasonably
supportive of IETF views and political correctness" one.

Were that situation to arise, I would expect the RSE to do a
balanced evaluation and the IAB, if it got involved, to do so
too, with both paying a lot of attention to the differences
among "note needed to ensure clarity about what the document
is", "note to warn against a diagnosed danger to the Internet
posed by the suggestions in the document", and "IESG wants to
get the last word in".  And, again, my personal view is that the
first two represent flaws in the document that ought to get
resolved, without add-on text, before the ISE agrees to publish
and that the third is not acceptable.   Put differently, I think
we have a problem any time the ISE (or other stream entity)
chooses to ignore, or reject without good reason, input about
changes to a document to make its status, or issues with its
suggested technology, clear.   

> So in other words what I am saying is don't invent process but
> follow existing pieces:
> 
> - last call the note in the IETF, to make sure the IESG
> actually represents IETF consensus --whereby the consensus is
> called by the IESG following normal process and appeal--, and
> go back to the ISE telling that the note has IETF backing.
> o if the ISE pushes back
> - consider this a disagreement between stream entities and
> follow RFC 5620 appeal process.

I think whether or not to do that Last Call should be up to the
IESG.  Nothing prevents them from invoking the "disagreement
between stream entities" procedures on their own remit, although
their position would certainly be stronger with clear IETF
backing.

> o if the RSE chooses sides with the ISE the note gets
> published but the IAB, the IESG, and the RSE have some serious
> talking to do because something is severely broken elsewhere
> than just the note. The RFC will most probably be published
> without the note but the IESG has the possibility to publish a
> "This RFC sucks for this reason RFC" while the real problems
> are being addressed

And we should operate on the guideline that, if the IESG simply
wants to dissent from a particular document, the mechanism is
publication of such an RFC, not attachment of notes.  But,
again, I believe that any situation in which a note is perceived
to be needed is a failure in the publication model _and_, if we
think notes are an appropriate way to resolve problems, that any
of the other streams should be able to ask the ISE to attach
notes of their choosing to IETF Stream documents, doing so as
soon as the Document Action or Protocol Action appears.

> Obviously publication of the document should be delayed on
> request from the IESG while the above is sorted out in a
> timely manner.

Yes, although the IESG (as well as the ISE and RSE) incur
considerably obligation to be timely if such issues arise.  The
ISE should be able to treat, e.g., IESG failure to produce a
position statement within a very short time after a Last Call
ends as an indication that the IESG has abandoned its position.

    john

---

From: "Polk, William T." <[email-masked]>
Date: Wed, 9 Sep 2009 09:53:42 -0400

Hi Robert,

> or even something like the NY Times.

IMHO, the RFC series (as comprised by the four document streams) is not
similar to IEEE Transactions on Networking or the NY Times.  I am not sure
that there is really a close analog out there.

> editor should have with the IETF.

The better question is, if IEEE was distributing the output of the IETF in
its series of standards publications and the IETF work was in conflict with
their own standards, would it be appropriate to publish without a note from
the IEEE explaining the incongruity?

And are we really helping anyone by not clarifying the relationship between
the document and other RFCs?  Shouldn't we provide this information as a
service to the reader?

Tim

---

From: "Polk, William T." <[email-masked]>
Date: Wed, 9 Sep 2009 15:08:38 -0400

> indexes and stuff like that excepted), but aside from that, there shouldn't

Yes, but everything that IEEE Transactions produces is similar in nature.
It is all personal submissions.  My point is that the RFC series is shared
by different communities with different submission policies.  I don't think
the analogy fits.  There is a completely different balancing act required.

> series is now, or ever has been.

I am not suggesting that the RFC series is IETF standards only, or should
be.  The streams coexist because they all provide services to the same
community.

> is what happens when it isn't - and who gets to decide.

I believe that when a requested IESG note is not appropriate, the RFC Editor
will push back and the IETF community will support that position.  If the
IESG is appropriate, but the RFC Editor pushes back, I believe the community
will make the right decision there.  Essentially, I trust that the IETF
community will ensure that the IESG does not abuse their position.  The
energy on this thread would seem to support my expectations...

Tim

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Sep 2009 08:30:59 -0700

> description of the RFC series:

It's certainly *not* what everybody knows; it's more like what
everybody's being told.

If you don't like a Wikipedia definition, change it. ;-)

Joe