Subject: Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt

From: John C Klensin <[email-masked]>
Date: Thu, 08 Oct 2009 13:36:54 -0400

Hi.

Some comments about the two possible dispute resolution models
-- appeals to the IAB with binding effect or appeals to the IAB
with only advisory effect on the RSE and ISE --that I had made
in an IAB context never made it onto the list, resulting in Jari
being surprised (for which I apologize) and some confusion about
what I intended and why.  An edited version of those comments
(there was mostly-unrelated context around the original notes
that isn't repeated here) follows:

I don't see much difference between the alternatives of "IAB
advice to the RFC Editor" and "IAB mandatory instructions to the
RFC Editor" in practice, but have a fairly strong pragmatic
preference for not having to open, or update, 4846.  I believe
that, whichever path is chosen, there needs to be a firm
requirement that the disagreement and its content be made public
if things move beyond a certain, fairly early, point.  I also
have my usual concern about getting too rigid about this sort of
thing -- if the ISE and RSE ignore strong advice from the IAB,
we have deeper and more serious problems than one IESG note and
will need to deal with those problems in some way.

It is probably also desirable that the statement in the draft
about attached notes, optional or mandatory, point to the
provisions of 4846 that permits withdrawal of a document at any
point.  In other words, there should never be any question that
the ISE or author can respond to a demand for a note by
withdrawing the document rather than publishing with the note or
applying other remedies.

While we've been surrounding this discussion with nice words to
the effect that there has never been a real problem and/or that
problems have been solved quickly, it isn't entirely true... and
the main reason why it is mostly true is that, in recent years,
the RFC Editor has backed down rather quickly when such issues
have
arisen, in part because the issues have been raised in contexts
that appeared to involve threats of contractual interference.
RFC 4846 was written in part to reestablish the independence of
the RFC Editor from unreasonable IESG demands; it would, IMO, be
sad to give that up over the principle of mandatory IAB
decisions about notes.   

Although I'm not aware of it happening in recent years, the same
ADs who became slightly notorious for holding up IETF work
indefinitely because it wasn't to their personal taste (the
people for whom the IESG eventually created internal
dispute-resolution policies) were sometimes equally aggressive
about trying to prevent publication of documents they found
distasteful as independent submission RFCs and/or to attach
obnoxious notes to them.  Of course, all of the occurred in the
dark; part of the historical problem here is lack of openness...
a situation that continues to this day when the only record of
the IESG discussion is a tracker note that there was an
objection.

As the IAB moves to select an ISE, the choices are presumably
not going to be limited to people who will uncritically accept
things that the IESG tells them.  With a strong and independent
ISE, if the IESG imposed a note that the ISE, the Editorial
Board, and the authors found really offensive, the ISE would
probably decide to not publish the document and might, instead,
propose to publish a document for the permanent record that
discussed the content of the original, the issues, the proposed
IESG note, etc.  Again, it would make little difference to that
scenario whether the instructions to the RFC Editor were
mandatory or not -- the principle and content would be the
issue.  I assume the IESG would want to attach a note to that
document too, although the ISE might then decide to attach
additional text explaining that the IESG was invited to write a
real commentary or response and decided to resort to
note-attaching instead.  Of course, good judgment on the part of
the ISE would get us into that situation only under the most
extreme of circumstances, circumstances that we can reasonably
predict will not occur.  But, if the circumstances are not real,
then the need for a mandatory override procedure isn't either.

As some comments to the IETF list have observed, the use of
"notes" is sometimes a lazy and responsibility-avoiding
alternate to actually engaging in a fair technical discussion. I
would hope that, if an issue like this reaches the IAB, the IAB
would insist on such a discussion and that a reasonable summary
of it be made public.  I don't think that needs to be written
down as a requirement.

The other piece of this is that the community has decided,
multiple times, that we want an Independent Submission process
that is actually independent... and, in particular, independent
of the IETF and IESG.  That consensus is clearly a rough one:
each time the topic has come up in the last decade or so we have
heard from people who are convinced that the Independent Stream
has outlived its usefulness and others who are convinced that it
should exist only to serve the specific needs and desires of the
IETF and IESG.  We had that debate at length when 4844 and 4846
were under discussion and it has intruded into this discussion
of 3932bis.

I see no reason -- nothing actually broken that needs fixing --
to change the balance.  I don't believe that the IESG has ever
had a reasonable request for change in a document ignored.   If
unreasonable requests are made, the proposed procedures,
including the requirement for notification and explanation, are
more than adequate to act as the basis for discussion, with the
IAB acting as mediator or referee (as 4846 provides) if its
members believe the topic is important enough.   Shifting toward
a model in which the IESG can force the IAB into a review and
then force the ISE to accept an IAB decision is just not
demonstrated to be necessary... necessary enough to justify
reopening 4844 and 4846 

Speaking pragmatically, I believe that creating a binding
inter-stream appeal process probably requires reopening both
4846 and 4844 and, given many of  the comments on the IETF list
about the previous drafts, would lead to our having to recycle
the discussion of the appropriateness of the role of the
multiple-stream model and whether the IESG gets a "first among
equals" role or better.  I don't believe that repeating that
discussion yet again would serve the community well and that is
another big argument for the advisory approach.

    john

---

From: Russ Housley <[email-masked]>
Date: Thu, 08 Oct 2009 14:12:31 -0400

>another big argument for the advisory approach.

I think everyone agree that the IAB has an oversight role here.  Many 
of the people on this list have already advocated the need for an 
appeals process to resolve disagreements about the content of notes 
suggested by the IESG.  This is not about the content of the document 
itself.  If it were, then I could understand your concern, but it is 
only about the content of the note.

Russ

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 09 Oct 2009 00:18:59 -0700

(moving this back to the IETF list, where the bulk of discussion has been.)

Russ Housley wrote:
> I think everyone agree that the IAB has an oversight role here.  Many of 
> the people on this list have already advocated the need for an appeals 
> process to resolve disagreements about the content of notes suggested by 
> the IESG.  This is not about the content of the document itself.  If it 
> were, then I could understand your concern, but it is only about the 
> content of the note.

Russ,

While the tenacity that you and the IESG are showing, and the apparent
motivation for it, are admirable, the effort seems to be based on some
assumptions that should be reconsidered.

The first assumption is that there is a real problem to solve here.  Given 40
years of RFC publication, without any mandate that the RFC Editor must include a
note from the IESG, and without any critical problems resulting, we have yet to
see any real case made for changing the current rule, which makes inclusion of
an IESG note optional.

The second assumption is that an IESG note is sometimes, somehow essential.  I
believe you will be very hard-pressed to make an empirical case for that
assumption, and the problem with trying to make only a logical case is that a
competing logical case is always available.  In other words, in 40 years of
RFCs, the damage that was caused by not having a note added by an authority that
is separate from the author, or the damage that was prevented by adding one, is
almost certainly absent.  That does not make it a bad thing to add notes, but it
makes the case for /mandating/ such notes pretty flimsy.

The third assumption is that the real locus of control, here, needs to be the
IESG.  Even though you are now promoting an appeal path, it's a fallback
position that derives from the assumption that the IESG should be the ultimate
arbiter of all quality assessment, not just for IETF RFCs but for all RFCs.  For
independent submissions, this distorts the original model, which is that the
IESG is merely to be consulted for conflicting efforts, not general-purpose
commentary on the efficacy or dangers of an independent document.  Really, Russ,
it's OK for some things to proceed without having the IESG act as a gatekeeper.

The fourth assumption is that an added layer of mechanism, in the form of an
appeal path, is worth the cost.  An honest consideration of those costs has been
absent, yet they are significant.

The fifth assumption is the odd view that Jari put forward, namely that creating
an appeal path somehow "retains the independence of the editor".  In other
words, impose a mechanism designed to reverse decisions by the editor, but say
that the editor retains independence.  Confusing, no?

The assertion that there is community support for adding this new appeal path is
apparently based a non-zero number of supporting posts, rather than on
satisfying the rather more stringent requirement to achieve rough consensus
support, or anything even close to it.  In other words, you got "some" support,
and based on that are claiming that it's the preferred solution.

Before adding more management layers, to solve a questionable problem, any claim
of community support ought to have stronger evidence than we have so far seen.

The IETF has a long history with how to handle calls for change:  Has it
achieved rough consensus?  In the absence of rough consensus the status is
supposed to remain quo.

The IESG is demanding a change.  The IESG has failed to achieve community rough
consensus for that change, but the IESG is still claiming a mandate for change.

One of the problems with our having rules is that we really are supposed to
follow them.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Oct 2009 06:19:06 -0400

Dave,

I'd like to address some of the points you made in your message to 
Russ re 3932bis:

>...

As ads for financial products remind us "Past performance is not a 
guarantee of future performance." Since we have been making changes 
in IETF functions over time, including the RFC Editor function, I 
don't think it is unreasonable to formalize this aspect of the 
relationship between the IESG and the RFC Editor, before a problem 
arises.

>makes the case for /mandating/ such notes pretty flimsy.

I believe that most folks recognize that the public, in general, does 
not distinguish between RFCs that are the product of IETF WGs, 
individual submissions, independent submissions, etc. I think the 
IESG has a legitimate role in ensuring that RFCs that are not the 
product of WGs are appropriate labelled, and inclusion of an IESG 
note is a reasonable way to do that.

When the RFC series was first established, the need for archival, 
searchable, open publication of Internet-related documents was a good 
argument for the autonomy of the RFC Editor function. Moreover, the 
RFC Editor function pre-dates the existence of the IETF and the IESG, 
by many years. But, times change. The availability of search engines 
like Google make it possible for essentially anyone to publish 
material that is widely accessible, relatively easy to find, and more 
or less archival. Also, the vast majority of the RFCs published for 
many years are documents approved by the IESG. Thus it seems 
reasonable to revisit the degree of autonomy the RFC Editor enjoys 
relative to the IESG. The current proposal does not change the 
relationship very much in practice, but I understand that it is an 
important issue in principle, and the IETF membership has debated it 
in this context, extensively.

>it's OK for some things to proceed without having the IESG act as a 

My comment above addresses this issue as well.

>absent, yet they are significant.

I think the biggest cost of an appeal mechanism is incurred when 
appeals arise, although there are costs associated with defining the 
mechanism. Since you argued above that we ought not expend a lot of 
effort to deal with problems that have not arisen, maybe we ought not 
worry about the costs of appeals that have not yet arisen :-).

>that the editor retains independence.  Confusing, no?

I agree that the quote cited above is not a good way to characterize 
the value of an appeals process. Perhaps a better way to state the 
value of the appeal process is to say that it provides a way for the 
Editor to address a situation when it believe that the IESG has 
insisted on inserting an inappropriate note.

I support 3932bis, with the appeal provision.

Steve

---

From: SM <[email-masked]>
Date: Fri, 09 Oct 2009 10:29:23 -0700

At 03:19 09-10-2009, Stephen Kent wrote:
>relationship between the IESG and the RFC Editor, before a problem arises.

By over-formalizing the procedures, the IETF will end up with a rigid process.

>I believe that most folks recognize that the public, in general, 
>does not distinguish between RFCs that are the product of IETF WGs, 

Section 1.1 of the draft mentions that:

   "The IESG may provide an IESG note to an Independent Submission or
    IRTF Stream document to explain the specific relationship, if any, to
    IETF work."

That's a "may".  From what you said, I deduce that you would prefer 
that line to say:

   The IESG will provide an IESG note to an Independent Submission ...

The reasons for the IESG Note are mentioned in Section 3.  None of 
them are about a label saying that the RFC is not a product of a WG.

>searchable, open publication of Internet-related documents was a 
>good argument for the autonomy of the RFC Editor function. Moreover, 
>the RFC Editor function pre-dates the existence of the IETF and the 
>IESG, by many years. But, times change. The availability of search 
>engines like Google make it possible for essentially anyone to 
>publish material that is widely accessible, relatively easy to find, 
>and more or less archival. Also, the vast majority of the RFCs 
>published for many years are documents approved by the IESG. Thus it 
>seems reasonable to revisit the degree of autonomy the RFC Editor 
>enjoys relative to the IESG. The current proposal does not change 
>the relationship very much in practice, but I understand that it is 
>an important issue in principle, and the IETF membership has debated 
>it in this context, extensively.

An open source advocate once suggested to me that I could use 
Geocities to publish material.  That site is closing this 
month.  There are differences between publishing something on your 
web site and publishing a RFC.  The latter does not require search 
engine optimization for wide dissemination.  A RFC has intrinsic 
qualities because of the way it is produced.  There are some RFCs 
with IESG notes, such as RFC 4144, which I read as good advice.

The current proposal undermines the independence of the RFC Editor 
(ISE in practice).  It changes the relationship from one where the 
various parties should work together and come to an agreement to a 
tussle between the RFC Editor and the IESG.  I don't think that an 
appeal is a good idea.  I didn't object to it as the IESG folks may 
feel better if they had that mechanism.  However, I do object to 
making the outcome mandatory.

>consensus for that change, but the IESG is still claiming a mandate 

There doesn't seem to be a concern about achieving rough community 
consensus in this case as the IESG really wants the change.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 Oct 2009 14:16:37 -0400

Dave:

You have the motivations for rfc3932bis completely confused.  The 
IESG is not the source for the proposed changes to RFC 3932.  RFC 
3932 as it stands works fine for the IESG, and the IESG continues to 
operate under it.  The Independent submission stream and IRTF stream 
do not like the IESG notes that are mandated by RFC 3932.  The 
approval of draft-iab-streams-headers-boilerplates by the IAB offers 
an opportunity to revisit this question.  So, you seem to be 
reviewing this discussion with the wrong context.

Below, I'll respond to each of you assumptions and assertions....

>>I think everyone agree that the IAB has an oversight role 
>>here.  Many of the people on this list have already advocated the 
>>need for an appeals process to resolve disagreements about the 
>>content of notes suggested by the IESG.  This is not about the 
>>content of the document itself.  If it were, then I could 
>>understand your concern, but it is only about the content of the note.
>
>While the tenacity that you and the IESG are showing, and the 
>apparent motivation for it, are admirable, the effort seems to be 
>based on some assumptions that should be reconsidered.

The document that was brought to Last Call did not have a section on 
appeals.  It was added because of the Last Call discussion.  I find 
it most interesting that the people voicing the strongest concerns on 
both sides of the issue are former IESG members.

>The first assumption is that there is a real problem to solve 
>here.  Given 40 years of RFC publication, without any mandate that 
>the RFC Editor must include a note from the IESG, and without any 
>critical problems resulting, we have yet to see any real case made 
>for changing the current rule, which makes inclusion of an IESG note optional.

This repeats points that were made in the Last Call discussion.

>The second assumption is that an IESG note is sometimes, somehow 
>essential.  I believe you will be very hard-pressed to make an 
>empirical case for that assumption, and the problem with trying to 
>make only a logical case is that a competing logical case is always 
>available.  In other words, in 40 years of RFCs, the damage that was 
>caused by not having a note added by an authority that is separate 
>from the author, or the damage that was prevented by adding one, is 
>almost certainly absent.  That does not make it a bad thing to add 
>notes, but it makes the case for /mandating/ such notes pretty flimsy.

This repeats points that were made in the Last Call discussion; 
however, several people wanted to include a path for dispute 
resolution before it was needed, not in the heat of the dispute.

>The third assumption is that the real locus of control, here, needs 
>to be the IESG.  Even though you are now promoting an appeal path, 
>it's a fallback position that derives from the assumption that the 
>IESG should be the ultimate arbiter of all quality assessment, not 
>just for IETF RFCs but for all RFCs.  For independent submissions, 
>this distorts the original model, which is that the IESG is merely 
>to be consulted for conflicting efforts, not general-purpose 
>commentary on the efficacy or dangers of an independent 
>document.  Really, Russ, it's OK for some things to proceed without 
>having the IESG act as a gatekeeper.

I disagree with this characterization.  The IESG is supposed to 
ensure that the non-IETF streams are not used as an end run around 
the IETF standards process or the IANA registration process for any 
IETF-related registries.  The whole point of RFC 3932 was to make 
this situation clear, and define process for it.  The IESG is not 
responsible for the quality of the content for RFCs outside the IETF 
stream.  The appeal path being discussed is about the content of an 
IESG note, not the content of the RFCs outside the IETF stream.

>The fourth assumption is that an added layer of mechanism, in the 
>form of an appeal path, is worth the cost.  An honest consideration 
>of those costs has been absent, yet they are significant.

This point was not in the Last Call discussion.  If your earlier 
assumption is correct, then this appeal path will never be 
exercised.  Others have stated that they expect it will be exercised 
quite soon.

>The fifth assumption is the odd view that Jari put forward, namely 
>that creating an appeal path somehow "retains the independence of 
>the editor".  In other words, impose a mechanism designed to reverse 
>decisions by the editor, but say that the editor retains 
>independence.  Confusing, no?

How can you call this an assumption?  I think Jari was very clear in 
his note, but I do not see it as an assumption.  Again, neither the 
IAB nor the IESG would be making any decision regarding the content 
of the published document.

>The assertion that there is community support for adding this new 
>appeal path is apparently based a non-zero number of supporting 
>posts, rather than on satisfying the rather more stringent 
>requirement to achieve rough consensus support, or anything even 
>close to it.  In other words, you got "some" support, and based on 
>that are claiming that it's the preferred solution.

The suggestion for this approach came from the Last Call 
discussion.  Neither of the document authors came up with the idea.

>Before adding more management layers, to solve a questionable 
>problem, any claim of community support ought to have stronger 
>evidence than we have so far seen.
>
>The IETF has a long history with how to handle calls for 
>change:  Has it achieved rough consensus?  In the absence of rough 
>consensus the status is supposed to remain quo.
>
>The IESG is demanding a change.  The IESG has failed to achieve 
>community rough consensus for that change, but the IESG is still 
>claiming a mandate for change.

The IESG is not demanding a change.  Quite the contrary.  The 
Independent submission stream and IRTF stream do not like the IESG 
notes that are mandated by RFC 3932.  The goal of rfc3932bis is to 
provide greater flexibility in this area, making IESG notes the exception.

>One of the problems with our having rules is that we really are 
>supposed to follow them.

Personally, I'd be happy to go back to an earlier version of 
rfc3932bis that does not include an appeal process.  However, that 
version of the document did not have community consensus (either).

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Oct 2009 09:16:24 +1300

Russ,

On 2009-10-10 07:16, Russ Housley wrote:
> Dave:
> 
> You have the motivations for rfc3932bis completely confused.  The IESG
> is not the source for the proposed changes to RFC 3932.  RFC 3932 as it
> stands works fine for the IESG, and the IESG continues to operate under
> it.  The Independent submission stream and IRTF stream do not like the
> IESG notes that are mandated by RFC 3932.  

Points well taken.

I think I'm going to challenge Jari's reading of rough consensus
in his message of Sept. 13:
http://www.ietf.org/mail-archive/web/ietf/current/msg58391.html

I think the discussions around the -09 and -10 drafts have actually
shown that there is no consensus to change from the current model,
reflected in the -08 draft, where the IESG merely *requests* the
editor to include an IESG note, and the IAB is involved only as
defined in RFC 4846.

Our general practice when there is no consensus to change a rule
is not to change it.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Sat, 10 Oct 2009 00:02:06 +0300

Dave,

> The first assumption is that there is a real problem to solve here.

I think there is a real problem, and that is the need to modernize the 
headers and boilerplates so that they are more reasonable for each 
stream. This includes things like getting rid of derogatory IESG notes, 
which none of us likes.

Of course, headers and boilerplates changes need to be accompanied by 
the corresponding change in 3932. THAT is the reason for the 3932bis 
draft. The trouble is, of course the final 3932bis needs to take the 
opinions of the community into account (and be acceptable to the 
approving bodies). This is why we have discussed all the changes. I do 
not see a lot of other options than the compromise position if 
completing 3932bis and the rest of the system of changes is the goal. We 
can have differing opinions on whether there's an issue with 
forcing/requesting IESG notes, but it is a fact that there are many 
people on both sides of this argument. I sincerely hope that we are not 
going to ignore their opinions and choose either extreme side as the 
final result.

Jari

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Oct 2009 08:51:43 +0700

Date:        Fri, 09 Oct 2009 14:16:37 -0400
    From:        Russ Housley <[email-masked]>
    Message-ID:  <[email-masked]>

  | You have the motivations for rfc3932bis completely confused.  The 
  | IESG is not the source for the proposed changes to RFC 3932.  RFC 
  | 3932 as it stands works fine for the IESG, and the IESG continues to 
  | operate under it.  The Independent submission stream and IRTF stream 
  | do not like the IESG notes that are mandated by RFC 3932.

I suspect that you, the IESG, and perhaps some others (perhaps even the RFC
editor) are confused as to the import of that RFC, or any RFC, in this area.

The IESG, and the IETF, simply do not have the power to tell the RFC editor
what to do, it isn't in the IETF's job description to do that.

Whatever the IESG says, whatever RFC3932 says, and whatever the result of
this current waste of everyone's time is, the RFC editor is completely
entitled (if he/she/it feels the need in a particular circumstance) to
simply ignore the IETF, the IESG, and anyone else not specifically having
some oversight capacity over the RFC editor (which does not include the IETF).

The RFC editor has agreed to send independent submissions to the IESG for
review, and that's fine, as it is for the RFC editor to accept advice from
the IESG (or anyone else the RFC editor decides to consult), or to reject
that advice if the editor believes that it doesn't advance the overall purposes
of the RFC series.

Nothing the IETF can do can change that, why is everyone wasting time on this?

kre

---

From: Jari Arkko <[email-masked]>
Date: Sat, 10 Oct 2009 10:52:33 +0300

Robert,

> what to do, it isn't in the IETF's job description to do that.

And that is of course true, and we do respect that. However, you are 
missing the fact there is two discussions ongoing, obviously the IETF is 
developing its own opinion but at the same time the larger community is 
updating the RFC editor model (h&b, independent submission model, rfc 
editor component split, etc). The latter work is formally lead by the 
IAB. This is the reason why I will NOT approve 3932bis solely based on 
IETF or IESG opinion, but have asked Olaf to ensure that whatever we do, 
the IAB is also happy with the end result.

(And this works two ways, by the way. My hands are tied with 3932bis if 
the non-IETF world is unhappy with it. Similarly, 3932bis is currently 
blocking the implementation of h&b.)

Jari

---

From: [email-masked]
Date: Sat, 10 Oct 2009 12:24:55 -0700 (PDT)

> By over-formalizing the procedures, the IETF will end up with a rigid process.

Or else it will end up with a bunch of rules that in practice nobody follows,
which is a recipe for a different sort of trouble.

But regardless of outcome, I agree with the sentiment that over-formalization
is bad.

> >note is a reasonable way to do that.

As yes, the old "people can't read" argument. The problem I have with this
argument is people who can't manage to comprehend the line at the top of a
specification that says "this does not specify a standard of any kind" are
highly unlikely to be able to assess the technical content of the document with
any degree of accuracy either.

And I somehow don't think anyone would be particularly pleased by dumbing our
specifications down to the first grade level, assuming that's even possible.

And while anecdotes are not data, I have to say I haven't seen any recent cases
of RFPs or whatnot referring to independent submissions. (Experimental
specifications, yes, but in these cases it was pretty clear the authors were
well aware of the status of the document and simply didn't care.) So perhaps
this problem isn't as severe as is sometimes claimed.

> them are about a label saying that the RFC is not a product of a WG.

Perhaps because such labels are already included, and when someone isn't
reading what the document says it really doesn't matter how many times you
repeat something.

> with IESG notes, such as RFC 4144, which I read as good advice.

RFC 4144 is an example of something which IMO doesn't happen often enough these
days - documents that comment on other specifications or processes, possibly
from points of view that do not reflect the consensus of the IETF but
nevertheless are worth preserving. It is important that it be clear these are
not consensus documents, but that'ss not the same as saying they should not be
part of the RFC series.

> making the outcome mandatory.

I have to agree.

> >community rough

> consensus in this case as the IESG really wants the change.

And regrettably, I have to agree with this as well.

				Ned

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Oct 2009 15:18:24 -0400

>them are about a label saying that the RFC is not a product of a WG.

I think may is the right term here. But, if the IESG chooses to 
assert this prerogative, I would like to see the note inserted, 
without the need for RFC Editor concurrence.

>>good argument for the autonomy of the RFC Editor function. 
>>Moreover, the RFC Editor function pre-dates the existence of the 
>>IETF and the IESG, by many years. But, times change. The 
>>availability of search engines like Google make it possible for 
>>essentially anyone to publish material that is widely accessible, 
>>relatively easy to find, and more or less archival. Also, the vast 
>>majority of the RFCs published for many years are documents 
>>approved by the IESG. Thus it seems reasonable to revisit the 
>>degree of autonomy the RFC Editor enjoys relative to the IESG. The 
>>current proposal does not change the relationship very much in 
>>practice, but I understand that it is an important issue in 
>>principle, and the IETF membership has debated it in this context, 
>>extensively.
>
>Geocities to publish material.  That site is closing this month. 
>There are differences between publishing something on your web site 
>and publishing a RFC.  The latter does not require search engine 
>optimization for wide dissemination.  A RFC has intrinsic qualities 
>because of the way it is produced.  There are some RFCs with IESG 
>notes, such as RFC 4144, which I read as good advice.

When the site closed, do you believe that all of the material 
published there will become inaccessible, not archived anywhere?  I 
doubt that.

>making the outcome mandatory.

The status quo does not mandate that the RFC Editor and the IESG 
agree; it allows the RFC Editor to make a unilateral decision to 
ignore an IESG note. So, I don't agree with the second part of your 
statement above. I do agree that the change diminishes the 
independence of the RFC Editor.

Steve

---

From: SM <[email-masked]>
Date: Tue, 13 Oct 2009 01:11:30 -0700

Hi Steve,
At 12:18 12-10-2009, Stephen Kent wrote:
>published there will become inaccessible, not archived anywhere?  I doubt that.

I am not sure whether all the material will be available at 
archive.org or other archiving sites.  If the material is archived on 
one site only, there's a risk of "too big to fail".  I can change the 
material I publish.  That's not always good if the material is to be 
used as a reference (immutability).  It took me some time to 
understand that sometimes we need access to an old version of a 
specification, and not the latest one, even if that version contains 
mistakes.  That's part of the intrinsic qualities I mentioned in my 
earlier message.

>independence of the RFC Editor.

You are trying to persuade me to change my stance while I am trying 
to persuade you to change yours.  It is in essence a dialogue.  If 
one of us is the authority which makes the decision, that person can 
make an unilateral decision and ignore the other person's 
opinion.  By invoking that authority, the person causes a break down 
of the dialogue.  When two parties are bound to work together on a 
regular basis, that can result in an uncomfortable situation.  Now, 
if we have to add an appeal (it's not being made in an individual 
capacity) to that, we can end up with a larger issue instead of a 
difference of perspectives between an individual and a body.

Let's step away from the draft being discussed for a few minutes and 
ponder on whether either of us is being unreasonable.  Now, if we 
cannot figure out the answer, let's ask (figuratively) someone else 
for advice.  We have the choice of accepting the advice even though 
we are right or seeking an advice that will suite us.

>demonstrated to be necessary... necessary enough to justify

I agree with John there[1].  Quoting Section 5 of RFC 4846:

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

   "As with the IESG review itself, the IAB's opinion, if any,
    will be advisory."

>any degree of accuracy either.

That's a good point.

>specifications down to the first grade level, assuming that's even possible.

We may be getting there if we read an IESG Note as parental guidance.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg58967.html

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Oct 2009 15:14:54 -0400

At 1:11 AM -0700 10/13/09, SM wrote:
>archive.org or other archiving sites.  If the material is archived 
>on one site only, there's a risk of "too big to fail".  I can change 
>the material I publish.  That's not always good if the material is 
>to be used as a reference (immutability).  It took me some time to 
>mistakes.  T

I agree with your observations, but I don't think that the RFC series 
is the only way to achieve the characteristics you cite.

>hat's part of the intrinsic qualities I mentioned in my earlier message.
>
>make an unilateral decision and ignore the other person's opinion. 
>By invoking that authority, the person causes a break down of the 
>dialogue.  When two parties are bound to work together on a regular 
>basis, that can result in an uncomfortable situation.  Now, if we 
>have to add an appeal (it's not being made in an individual 

Good points. My view is that a shift in the balance of power is 
appropriate, and that an appeal process can increase confidence that 
the IESG will not abuse its power (if granted). But, that is not a 
guarantee. Not sure about your last sentence above, since the RFC 
Editor is no longer an individual, but a function effected by a set 
of individuals. At least the IESG, another set of individuals,  least 
appointed through in open process, unlike the RFC Editor.

>we are right or seeking an advice that will suite us.

Of course you and I are reasonable people :-). Not sure how the rest 
of the paragraph above fits into our discussion though.

Steve

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Oct 2009 00:24:29 +0300

John,

I do not personally have a problem with any of the suggested models, 
including yours.

However, I have a problem in how we are discussing this topic. It has 
already been established a long time ago that you and many other people 
have strong opinions about this matter, and its easy to find arguments 
to support all those opinions. This is why we have been trying to find a 
middle ground that finds a reasonable balance between keeping the RFC 
Editor as an independent publisher and allowing important labels to be 
attached in exceptional situations. It is not news that what we proposed 
as a compromise position isn't optimal from some people's point of view. 
But a small number of voices should not drive the entire community's choice.

So, may I ask that if we propose some other resolution, we talk not just 
about why that's a great proposal, but also how the proposal addresses 
the diverging opinions from various sides of the argument? I am not 
claiming by any means that the proposal that we sent out is the right 
one, but I think we need to try to honor the different opinions in some 
manner. The folk who want as much independence as possible for the RFC 
Editor, those who want the ability to put in mandatory notes, etc. FWIW, 
several of us believed we had a model that was acceptable to most of us 
and could be approved in the two relevant bodies. If that's not the 
case, too bad, but this means that we have to find a new compromise that 
works for everyone or decide that we have sufficiently rough consensus 
to move on anyway. Its NOT enough to change the proposal so that whoever 
was unhappy now becomes happy. Negotiation 101. I already checked and 
the other extreme camp feels your suggested changes are unacceptable.

Also, I believe the first order of priority is to find out what the IETF 
and the larger community wants to do here. Lets do the right thing, and 
put the process questions (such as which RFC needs to be updated) aside 
for the moment. We will find a way to solve those things, they should 
not drive the big decisions.

I also want to remind everyone that it matters very little what the 
difference between various versions of this document have been. The only 
thing that matters is that we come to an end result that is (perhaps 
somewhat grudgingly) accepted by most of us so that we can get the new 
headers into use!

Jari

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Oct 2009 18:36:14 -0700

Jari,

Jari Arkko wrote:
> It is not news that what we proposed as a compromise position isn't optimal 
> from some people's point of view. But a small number of voices should not 
> drive the entire community's choice.

We agree, yet oddly land on different sides.

A review of the public record shows relatively minimal voiced support for the
IESG insistence that it be able to override the RFC Editor's decision.

That is, my reading of the record says that the small number is on the side of 
terminating the multi-decade RFC Editor independence. Perhaps my reading is 
wrong.  An accounting assessment of community views, justifying claims of rough 
consensus, is the usual approach towards resolving this kind of disparity.

> Also, I believe the first order of priority is to find out what the IETF and 
> the larger community wants to do here.

In the face of a complex problem space, combined with a complex solutions space,
and controversy about both, the first priority should be to establish rough
consensus about the problem that is intended to be solved.

That hasn't been done.

Get us to agree on the nature of the "problem" and its degree of severitym --
and therefore the dangers that come from not "solving" it -- and we might be
able to get some common perspectives on solutions.

d/
-- 

   Dave Crocker

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Oct 2009 15:16:44 +0300

Dave,

> An accounting assessment of community views, justifying claims of 
> rough consensus, is the usual approach towards resolving this kind of 
> disparity.

That sounds like a fine plan. We got most input during the third last 
call when I asked whether the notes should be optional or mandatory. My 
notes indicate maybe a dozen people on both sides of that particular 
question, and that's the basis of my claim that there are people on 
different sides of this argument. Since then we have had less people 
participating in the discussion.

How would you like us to progress on this then? Do you want me to do a 
recount :-) I could easily have been wrong. Or is this more about when 
we are polling people? But I fear that all except the die-hards have 
left the thread.

> relatively minimal voiced support for the IESG insistence

Or are you suggesting that we should exclude some people who stated an 
opinion, such as the ADs? But if we exclude IESG members and RFC Editor 
board members and those who hold some position in the RFC Editor 
function, its going to be a lonely discussion... :-D

Jari

---

From: John Leslie <[email-masked]>
Date: Fri, 16 Oct 2009 08:54:45 -0400

Dave CROCKER <[email-masked]> wrote:
> Jari Arkko wrote:
> 
>> It is not news that what we proposed as a compromise position isn't 
>> optimal from some people's point of view. But a small number of voices 
>> should not drive the entire community's choice.
> 
> A review of the public record shows relatively minimal voiced support
> for the IESG insistence that it be able to override the RFC Editor's
> decision.

   Straw man alert!

   There has been "minimal voiced support" for that "insistence" because
it simply doesn't exist.

   The IESG has suggested that if it comes to consensus that a IESG note
be attached, the "RFC Editor" should respect that consensus. It has
always been understood that further discussion of the wording of such
a note is appropriate.

   The IETF-consensus that Jari tried to call was that the RFC Editor
should document a disagreement with a proposed IESG note and be prepared
to present that to the IAB if agreement can't be reached with the IESG.

   If I may digress, it is my strong opinion that should such a situation
ever arise (it doesn't seem terribly likely!), it's nearly certain that
the IAB should tell one or the other to "Stop doing that!"; and that
only the IAB has enough clout to make that stick.

> That is, my reading of the record says that the small number is on the
> side of terminating the multi-decade RFC Editor independence.

   I'm not quite sure whether that's a straw-man.

   The IESG opinion isn't to "terminate" "independence"; so it's hardly
surprising that few folks are speaking in favor of that.

   But it's quite possible that John Klensin, Brian Carpenter, and
Dave Crocker see the IESG proposal as "terminating" "independence".

   There have been a number of voices favoring what Jari tried to call
as consensus, and I'd like to add mine. If there was "independence"
of the RFC Editor from IAB oversight, it's long gone, and good riddance
IMHO. Jari's proposal included quite enough "independence" from the
IESG, IMHO. Document Editors, in the IETF, are supposed to be seeking
consensus; and I see no reason why the RFC Editor shouldn't share
at least a bit of responsibility to seek consensus.

> Perhaps my reading is wrong.

   I suspect, Dave, that you are reading something into Jari's proposal
that isn't there. It might help if you tried the exercise of explaining
_exactly_ what Jari is proposing -- not just what harm it would inflict
upon your worldview of the ideal RFC Editor.

> rough consensus, is the usual approach towards resolving this kind of 

   Well, I suppose you've been following IETF a lot more closely than
I over the last twenty years; but that's not the "usual approach" I've
been seeing.

   The "usual approach" I've seen is to start with a call of consensus
and have anyone who disagrees state where s/he thinks the caller has
gone wrong: the caller or a body hearing an appeal then reviews the
record and states in considerably more detail what they see as the
most likely consensus. Then discussion can continue, with much of the
ambiguity brought out into the open. If the person who disagrees is
not satisfied, higher-level appeals are available.

   I do not see "justifying" here: I see disambiguating. I do not see
any claims that the whole "community" has been heard from: I see a
record of considering the points raised by the subset that has been
heard from.

>> and the larger community wants to do here.

   You're quoting Jari out of context. Let me restore the context:
] 
] So, may I ask that if we propose some other resolution, we talk not
] just about why that's a great proposal, but also how the proposal
] addresses the diverging opinions from various sides of the argument?
] ...
] Also, I believe the first order of priority is to find out what the IETF
] and the larger community wants to do here. Lets do the right thing, and
] put the process questions (such as which RFC needs to be updated) aside
] for the moment. We will find a way to solve those things, they should
] not drive the big decisions.

> In the face of a complex problem space, combined with a complex
> solutions space, and controversy about both, the first priority
> should be to establish rough consensus about the problem that is
> intended to be solved.
> 
> That hasn't been done.

   Indeed, it hasn't.

   It escapes me, however, _why_ we should take on such a task.

   The IESG and IAB are trying to implement changes to boilerplate,
reflecting changes in the IETF community's views of the role of the
IESG in non-IESG documents published by the RFC Editor.

   Changes to an old consensus are always difficult. There are a
number of "problems" which led to this attempt to update. Documenting
all of them would only serve to obfuscate.

   Progress so far in this task has reduced the role of the IESG in
such documents. Tying this process in knots over details nobody claims
are likely to arise in the near future doesn't strike me as helpful.

> Get us to agree on the nature of the "problem" and its degree of
> severity -- and therefore the dangers that come from not "solving"
> it -- and we might be able to get some common perspectives on
> solutions.

   That is not a reasonable request.

   The IESG has been trying to work from principles, not from a
"problem statement." This process didn't start from a "problem"
between the IESG and the RFC Editor -- there has been no "problem"
there for several years at least.

   Problem Statements are something we ask of Working Groups when
there is ambiguity in their charter. They take a long time to write,
and they almost always turn up parts of "the problem" which the WG
will end up unable to solve.

   I urge you to do as Jari asks: talk not just about why your
proposal is good, but about how it addresses the diverging opinions
expressed so far.

   If you're not willing to do that, please either file an appeal,
or stop beating this "pining for the fjords" horse.

--
John Leslie <[email-masked]>

---

From: Lars Eggert <[email-masked]>
Date: Sat, 17 Oct 2009 11:53:44 +0300

On 2009-10-16, at 15:54, John Leslie wrote:
> as consensus, and I'd like to add mine.

+1

Lars (assuming my voice counts)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Oct 2009 17:03:31 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> Dave,
    >> An accounting assessment of community views, justifying claims
    >> of rough consensus, is the usual approach towards resolving
    >> this kind of disparity.

    Jari> That sounds like a fine plan. We got most input during the
    Jari> third last call when I asked whether the notes should be
    Jari> optional or mandatory. My notes indicate maybe a dozen
    Jari> people on both sides of that particular question, and that's
    Jari> the basis of my claim that there are people on different
    Jari> sides of this argument. Since then we have had less people
    Jari> participating in the discussion.

    Jari> How would you like us to progress on this then? Do you want
    Jari> me to do a recount :-) I could easily have been wrong. Or is
    Jari> this more about when we are polling people? But I fear that
    Jari> all except the die-hards have left the thread.

I certainly have.  I listened until I thought I understood the other
positions, I wrote until I thought I had done a reasonable job of
stating my position, but more back and forth doesn't seem to be
productive.  So, my only participation at this point is to state from
time to time that I think the process is reasonable.