Subject: Re: [rfc-i] RSOC name

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2019 13:06:46 +1200

As I said in my rant at https://www.cs.auckland.ac.nz/~brian/CommentaryIAB.pdf, "oversight" of the RFC Editor is not mentioned in the IAB Charter (and this was not an oversight, in the other sense of the word). So I think the name has been sending the wrong signal all along, and both the name and the mandate need to be updated accordingly.

We should take this discussion to the rfc-interest list now, IMHO.

Regards
   Brian

On 30-Jul-19 11:15, Donald Eastlake wrote:
> I don't think the IAB project model fits very well for the RFC Series
> and that it should have different governance for which I have some
> ideas. But I wanted to talk about something else: the power of
> nomenclature.
> 
> The key word in RFC Series Oversight Committee is "Oversight". What do
> people think when they hear "oversight"? They think that a large part
> the job of whoever has "oversight" is to review and criticize. No
> doubt the fine print clarifies things but every time someone thinks
> about or volunteers for or is appointed to the RSOC, it rings the
> "oversight" gong. Of course there are plenty of worse words than
> "oversight". I suppose it could have been called the RFC Series
> Management Committee or something...
> 
> What if everything else we the same, but it had been called the RFC
> Series Support Committee? And everytime someone thought about or
> volunteer for or was appointed to the committee they were reminded
> that this is about supporting the RFC Series?
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  [email-masked]
> 
> .
> 
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2019 15:53:15 +1200

Andrew,
On 30-Jul-19 15:04, Andrew Sullivan wrote:
> Hi,
> 
> As ever, I do not speak for the Internet Society though I am employed
> by it.  I'm posting this note especially because I have certain
> experiences not widely shared: I was all of an IAB member, an IAB
> chair, an IAOC member, and an IAOC chair during some portion of the
> past where various bits of RFC 6635 applied.
> 
> On Mon, Jul 29, 2019 at 07:15:10PM -0400, Donald Eastlake wrote:
> 
>> the job of whoever has "oversight" is to review and criticize.
> 
> I don't think that.  What I think is that it is the responsibility of
> the oversight body to ensure that the thing to be overseen is
> accomplished according to some conditions.  I'd like to think that the
> conditions are well-operationalized so that people are in a position
> to know about this.
> 
> The fundamental basis of oversight is the ability to decide whether a
> given overseen thing is or is not adequately done.  At a high level,
> this generally works out to "hire and fire" capability.  (Note you can
> do it other ways.  Gating-function, for instance, could do this, but
> it seems unwise to implement.)
> 
> That capability with respect to the RFC Series Editor goes back at
> least to RFC 2850, which says, "The IAB must approve the appointment
> of an organization to act as RFC Editor and the general policy
> followed by the RFC Editor."  This is of course far less concrete than
> the full blown-out description found in RFC 6635.  But the basic rule
> is already there.

No, I really don't agree. I was the editor of RFC 2850. It uses the term
"oversight" explicitly in the phrases "Architectural Oversight" and
"Standards Process Oversight and Appeal", but not in reference to the
RFC Editor. It uses a quite different formulation: "The IAB must approve
the appointment of an organization to act as RFC Editor and the general
policy followed by the RFC Editor." This was not an accident of drafting.
(At that time, the organization was ISI and the general policy was created
by Bob Braden and Joyce Reynolds, but we didn't expect that to last for
ever, and it didn't.)

I now believe that the reformulation including "oversight" in RFC5620,
updated in RFC6635, was a collective error, which I certainly missed
at the time. Particularly, the phrase "The IAB retains its oversight
role..." in RFC5620 was inappropriate IMHO, because there was previously
no such formal oversight role to retain.

Would you say that the IAB, whose membership is approved by the ISOC Board,
is therefore under the oversight of ISOC?

I think we got this wrong and now we are paying the price.

IMHO the long term fix will be an "RFC Editor Model (Version 3)" that
underlines and guarantees the independence of the RFC Series and its Editor.

To be clear, of course the production and publication contracts need
proper contract management, but that is more of an IETF LLC role.

> I don't know what the world would be like in the case of
> terminological change like you propose.  But I would like to suppose
> that everyone involved in the IAB, at least, and anyone I (at least)
> ever asked to be on the RSOC regarded their role as making the RFC
> series successful.  
I'm sure that's correct.

> And making the Editor's general policy cohere with
> the IAB's agreement is no innovation from 6635: it's right there in
> 2850.  It was also in RFC 1601 and RFC 1358.  I am not too sure that
> the responsibility of the IAB for this issue is grounded in anything
> earlier than 1358, but I'm also not sure that a responsibility that
> has been repeatedly affirmed in print since 1992 is one that we can
> assume is inoperative.

I still don't see how approving a policy morphed into oversight, which
seems to have morphed further in recent times. By telling a group of
people that they had oversight, we unintentionally set the scene for
things to go wrong.

> Elsewhere, Mike StJohns has claimed, "This is a senior person who
> really should be co-equal with the IAB and IESG."  I do not find the
> documented tradition that suggests this is true.  On the contrary, I
> can find documents stretching back to at least 1992 (where I stopped
> digging) suggesting that the RSE is in fact subordinate to the IAB.

Well, that is obviously a matter of interepretation, but my preferred
phrasing is that the relationship should be "collegial".
(https://www.merriam-webster.com/dictionary/collegial)
That matches what I observed most of the time until very recently.

> That is not to suggest the relationship is some sort of
> directive-management one.  In my current job, I have plenty of
> colleagues who know more about their area than I do (i.e. all of
> them), yet I am responsible for their direction and in this formal
> sense they are "subordinate" to me.  If any of them messes up, they
> are not responsible to my board: I am.  Co-equal suggests that perhaps
> the RSE ought to be picked by nomcom.  I'm not too sure that is
> desirable.

Since the skill set is not one we commonly find in our own community,
I agree with you there. A search committee model seems more appropriate.

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Jul 2019 13:11:45 +0200

Hi Brian and Andrew,

> On 30 Jul 2019, at 05:53, Brian E Carpenter <[email-masked]> wrote:
> 
> (https://www.merriam-webster.com/dictionary/collegial <https://www.merriam-webster.com/dictionary/collegial>)

My memory aligns pretty well with what Mike wrote, and I would add a bit of flavor.

Lest there be any doubt about who had the last word as to what went into an RFC back then, it was Jon and no one else.  Jon made this point very clearly at the 1991 Atlanta meeting, in which a shouting match took place during the plenary between him and Frank Kastenholz, chair of the Ethernet-MIB working group after Jon changed some variables before releasing the final copy.  Jon’s position at the time, after shouting expletives from the back of the room was, “I am not going to publish a faulty specification as an RFC.”  It was notably the “I” word that stood out then as it does now.(*). You can find the more politely minuted version of this debate on Page 29 of the Proceedings.

The IAB backed Jon up, probably because he was right about the technical error, even if the process wasn’t well defined.  And so that did lead to a discussion about the IAB’s role in the process, well prior to the Kobe Cabal and Boston Massacre; but in my memory, neither Jon nor Bob wavered from their positions that they were final arbiters over the series, though neither actively sought confrontation with the IETF or the IAB, but instead sought to facilitate the organization’s goals.  The limits of the RFC Editor’s authority has never really tested.

This trip through memory lane explains the past, but doesn’t dictate the future.

Eliot
(*) This, by the way, was my introduction to Jon Postel.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jul 2019 11:18:39 -0400

Hi,

Previous disclaimer still in effect.

This is a reply to three messages at once, because I think they're all
related (though it makes this message rather long).  I take Brian's
point about this being really about the RFC Editor history, so I've
stayed with that list and trimmed the ietf list because threads that
span two lists are unmanageable.

> by Bob Braden and Joyce Reynolds, but we didn't expect that to last for

I did not and do not think it's an accident of drafting.  But I don't
think the difference makes the difference you seem to think it does,
and it would be interesting to me to understand why you think it does.

If the IAB must approve the appointment of an organization, and must
approve the general policy, then it follows that such approval could
be withdrawn.  Under such a withdrawl, it seems to me, only one of
two things could be true:

	1.  The RFC Editor in such a case would be terminated in that
	position.
	2.  That part of RFC 2850 would be shown to be inoperative.

I gather we never exercised this part, so it's not clear to me what
the outcome would be.  But if (1) is true, then the IAB's role in this
case is very much one of "oversight".  I don't even know what else we
could call it.  And of course, if (2) is true then we are simply
admitting that there isn't any rule about the RFC Editor at all.

> is therefore under the oversight of ISOC?

Actually, the IAB's membership is not _approved_ by the ISOC Board of
Trustees, but _confirmed_ by it.  That is, the board receives a
recommendation from the nomcom and then at a moment in time says,
"Yes, that's fine," and then steps away.  The BoT doesn't have a
mechanism to withdraw its approval.

If what you are claiming is that RFC 2850's use of "approve" is actually
intended to mean "confirm", then that is at the very least unclear.
Moreover, the ambiguity persisted through the period in which the new
model was adopted, and it does not appear that the use of "oversight"
in model 2 was something people found surprising.  This suggests that,
whatever one might feel about what one's intentions were in the past,
it is at least an open question about exactly how people imagined
things to work when the text was written.  We are not, after all,
infallible repositories of information even about our own pasts, never
mind the past of a whole community.

> That matches what I observed most of the time until very recently.

I don't see anything strange about the idea that people can be
collegial (in sense 3 from your link) and yet in a formal relationship
where one is formally subordinate to the other.  Indeed, every time I
manage anyone, I strive to make that the case.  I don't want to be
"the boss" and I usually find people who do to be tiresome and
unimaginative.  And we are talking about a contracted relationship
here, so _someone_ is going to have to have some sort of power over
the other; so it cannot be sense 2 in any absolute way, or the
contracted party would be part of the group making the decision about
hiring the contracted party, which is an obvious conflict of interest.

> I agree with you there. A search committee model seems more appropriate.

But how would one then decide on the search committee?  

On Tue, Jul 30, 2019 at 04:02:37AM -0400, John C Klensin wrote:
> Andrew,
> 
> As someone with a history that is less distinguished than yours

In case it was not clear, I wasn't reciting my history with this to
suggest I'm particularly distinguished (though it may suggest a
certain foolhardiness), but just to indicate the bits of memory I
might have (unreliable though my memory may be).

> Consensus on
> the IAB or IESG (even if it reflects IETF community consensus)
> does not make something true

Obviously.  Of course, these documents are enshrined as RFCs that were
in fact published by RFC Editors who presumably had some opinion on
the topic.  And so …

>  Jon
> definitely thought that he had the authority to simply refuse to
> publish a document if its technical quality was unacceptable (to
> him).

… it seems significant that these documents were published by RFC
Editors.

> So, whatever one decides to do, it should not be based on the
> assumption that the RFC Editor function (and what we now call
> the RSE role) has always been in a subsidiary relationship to
> the IAB or even that the IAB has had the authority to hire and
> fire for a long time.

I don't think it's an _assumption_.  It's what people wrote down, in
RFCs that were published by RFC Editors who, we are now claiming,
didn't believe that.  One supposed advantage of the RFC series is that
it's archival.  If we're now claiming that it's also full of errors
about what the real facts were, we maybe have an even bigger problem
than we think we do.

On Tue, Jul 30, 2019 at 01:11:45PM +0200, Eliot Lear wrote:
> 
> Jon’s position at the time, after shouting expletives from the back of the room was, “I am not going to publish a faulty specification as an RFC.”  It was notably the “I” word that stood out then as it does now.
> 

I note in what you say there that the IAB "backed Jon up", and I think
that's an important bit of evidence that this really _was_ a collegial
relationship as Brian asserts above.  But the point is still that the
limits of the authority aren't tested in part because those who hold
the role need to have a good sense of what they can and can't do as a
practical matter.  This becomes even more important when, as happened
the last time, the role is filled by someone who is not as qualified
(and does not pretend to be) to speak about technical details as Jon
Postel was.  Moreover, this is a relationship in which there is not
insignificant money changing hands -- money that comes from the IETF's
funds and that needs to be managed for the benefit of the IETF.  Such
a relationship simply entails that someone needs to have the power to
hire _and fire_ the role.

I should think this to be obvious.  For imagine that we are in an
alternative world in which the RFC Editor turned out to be a mole for
OSI protocols.  Imagine that said Editor kept inserting observations
about the presentation layer into all the IETF documents, unilaterally
relying on the authority of the RFC Editor to do this.  Presumably, we
would need to do something about that behaviour, and I would like to
believe that we think it is something we _could_ address.  If we
actually think we couldn't, then that seems like a good argument to
stop using RFCs as the means of publishing IETF standards.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Jul 2019 11:46:51 -0400

I find the most enjoyable work environments are those in which people are
treated as peers.  I am a bit shocked that there is discussion about people
being "subordinate" when they are experts in their field and extremely well
regarded.  Perhaps we could get beyond the general behavior issues if
everyone took on the attitude that they are working with peers, be that the
IAB to IESG to RSE to IETF secretariat or any of those with the community
participants.  When in an I* role, it is well known that you will fold back
into the community at some point and you are a peer, just with a current
role to serve (at the pleasure of the community).  If you are then
appointed to a another role, WG chair, etc., you should expect to work with
chairs as peers and WG members as peers (many of them are likely far more
senior in day jobs anyway).  I'm generalizing this as the thought process
trickles and has a bigger impact not just on the RSE and finding the best
fit going forward, but on the community as a whole.  It works better when
we all regard each other as peers, IMO.

Best regards,
Kathleen

On Tue, Jul 30, 2019 at 10:29 AM <[email-masked]> wrote:

> Inline.
> I was on the IAB at the time this document was developed and remember the
> disussions. This distinction was intentional.
>
> I am in complete agreement with Brian on this.
>
> Agreed, although it isn't clear to me that all of this can wait for the
> long term.
>
> Indeed we did.
>                                 Ned

-- 

Best regards,
Kathleen

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jul 2019 09:02:30 -0700

On 7/30/2019 4:11 AM, Eliot Lear wrote:
> ...
>
> *_Lest there be any doubt about who had the last word as to what went
> into an RFC back then, it was Jon and no one else._*

That was true then, in 1991. But that power did not last, and after 1992
it was effectively withdrawn.

>   Jon made this point very clearly at the 1991 Atlanta meeting, in
> which a shouting match took place during the plenary between him and
> Frank Kastenholz, chair of the Ethernet-MIB working group after Jon
> changed some variables before releasing the final copy.  Jon’s
> position at the time, after shouting expletives from the back of the
> room was, “I am not going to publish a faulty specification as an
> RFC.”  It was notably the “*I*” word that stood out then as it does
> now.(*). You can find the more politely minuted version of this debate
> on Page 29 of the Proceedings. 

This was also a hot topic during the next meeting, in 1991 in Santa Fe.
And indeed, one of the debate in the meeting was whether "we should get
rid of the IAB".

>
> The IAB backed Jon up, probably because he was right about the
> technical error, even if the process wasn’t well defined.  And so that
> *did* lead to a discussion about the IAB’s role in the process, well
> prior to the Kobe Cabal and Boston Massacre; but in my memory, neither
> Jon nor Bob wavered from their positions that they were final arbiters
> over the series, though neither actively sought confrontation with the
> IETF or the IAB, but instead sought to facilitate the organization’s
> goals.  The limits of the RFC Editor’s authority has never really tested.

That is not my understanding. In fact, the post Kobe reaction was pretty
much informed by the Ethernet event. A lot of the debate was about the
checks and balance of the IETF, and specifically whether and how the
consensus of a working group could be overwritten. In the pre-Kobe
organization, the IAB was on top, and the IETF was defined very much as
an activity organized and supervised by the IAB. The RFC Editor was part
of that organization, definitely on top of the working group.

Post Kobe, that changed. The IAB's powers were pretty much vacated. The
power to review and approve standard track RFC was moved to the IESG,
which itself was constrained by process. The community did not want to
have some external authority exert arbitrary power, whatever the
curriculum and historical achievements of this authority. So there is a
reason why none of RFC editors ever tried to block the publication of an
IESG-approved RFC. They simply do not have that power. It was removed in
the post 1992 organization.

The RFC editor, and now the stream editor, do on the other have the
power to publish RFC that the IESG does not approve. I personally think
it is an important parts of the process, to balance the power of working
groups and the IESG and ensure that a diversity of opinions can be
expressed. That's pretty much the point that was reaffirmed in RFC 1796.

> This trip through memory lane explains the past, but doesn’t dictate

Absolutely. The main focus of the IETF ought to be the future, not the
past. The past provides us with guiding principle, open standards for an
open Internet. But the present story is one of gradual shrinkage. The
IETF gave up standardizing the web, the mobile networks, or the access
networks. We have a hard time bringing in new work that instead develops
in open source projects. In general, we have a hard time attracting
young people. If the trend continues, the IETF will continue shrinking
and concentrate on core protocols like IP, TCP, DNS, BGP, TLS and HTTP,
until some enterprising groups start chipping at that too. As the IETF
influence diminishes, so will the importance of the RFC series. I don't
think we are going to solve that by having our eyes fixated on the past
glories of the 80's.

-- Christian Huitema

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Jul 2019 07:18:01 -0700 (PDT)

Inline.

Indeed we did.

				Ned

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Jul 2019 12:55:42 -0400

On Tue, Jul 30, 2019 at 12:29 PM Christian Huitema <[email-masked]>
wrote:

> *Lest there be any doubt about who had the last word as to what went into
> an RFC back then, it was Jon and no one else.*
>
>   Jon made this point very clearly at the 1991 Atlanta meeting, in which a
> shouting match took place during the plenary between him and Frank
> Kastenholz, chair of the Ethernet-MIB working group after Jon changed some
> variables before releasing the final copy.  Jon’s position at the time,
> after shouting expletives from the back of the room was, “I am not going to
> publish a faulty specification as an RFC.”  It was notably the “*I*” word
> that stood out then as it does now.(*). You can find the more politely
> minuted version of this debate on Page 29 of the Proceedings.
>
> And indeed, one of the debate in the meeting was whether "we should get rid
> of the IAB".
>
>
> The IAB backed Jon up, probably because he was right about the technical
> error, even if the process wasn’t well defined.  And so that *did* lead
> to a discussion about the IAB’s role in the process, well prior to the Kobe
> Cabal and Boston Massacre; but in my memory, neither Jon nor Bob wavered
> from their positions that they were final arbiters over the series, though
> neither actively sought confrontation with the IETF or the IAB, but instead
> sought to facilitate the organization’s goals.  The limits of the RFC
> Editor’s authority has never really tested.
>
> organization, the IAB was on top, and the IETF was defined very much as an
> activity organized and supervised by the IAB. The RFC Editor was part of
> that organization, definitely on top of the working group.
>
> power to review and approve standard track RFC was moved to the IESG, which
> itself was constrained by process. The community did not want to have some
> external authority exert arbitrary power, whatever the curriculum and
> historical achievements of this authority. So there is a reason why none of
> RFC editors ever tried to block the publication of an IESG-approved RFC.
> They simply do not have that power. It was removed in the post 1992
> organization.
>
> The RFC editor, and now the stream editor, do on the other have the power
> to publish RFC that the IESG does not approve. I personally think it is an
> important parts of the process, to balance the power of working groups and
> the IESG and ensure that a diversity of opinions can be expressed. That's
> pretty much the point that was reaffirmed in RFC 1796.
>
>
> open Internet. But the present story is one of gradual shrinkage. The IETF
> gave up standardizing the web, the mobile networks, or the access networks.
> We have a hard time bringing in new work that instead develops in open
> source projects. In general, we have a hard time attracting young people.
> If the trend continues, the IETF will continue shrinking and concentrate on
> core protocols like IP, TCP, DNS, BGP, TLS and HTTP, until some
> enterprising groups start chipping at that too. As the IETF influence
> diminishes, so will the importance of the RFC series. I don't think we are
> going to solve that by having our eyes fixated on the past glories of the
> 80's.
>

The IETF could stop treating newcomers as subordinate and thus inferior and
instead consider work that's been outside of current participants purview
more openly to cultivate it and they may try harder to then bring that work
in.  I've seen several recent cases where work was not encouraged despite
interest, where it should be cultivated instead of turned away.  This is
getting onto a separate topic, but goes back to treatment of participants
across the board.  In terms of protocols, we have quite a bit in the
routing overlay space and in security, there is plenty of new work on
endpoints (TEEP, SUIT, and RATS are all fairly new).

Do we really need to talk about "power" and people being "subordinate"?  If
subordinate were talked about as "in support of", I could buy into that but
not as "inferior" in which actions can easily be taken on their
role/position.  In all the presented options, there are ways to end
contracts or positions and there are ways to assume a high level of respect
for peers and instill that into our culture.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 30 Jul 2019 19:21:40 +0200

Hi Andrew,

On 2019-07-30 17:18, Andrew Sullivan wrote:

 ...

> about what the real facts were, we maybe have an even bigger problem

I think there is a difference between what the RFC Editor at the time
read the document as saying, and what some people recently has read
it as saying.  "Oversight" is a quite broad concept, that (unfortunately,
in this case) can be read to mean a variety of things to different people.

I submit that the RFC Editor may have read it as describing the status
quo at the time of publication, without any intention of morphing the
IAB function with respect to the RFC Editor into something very different
from what was practised at that time, to the extent that it was described
in RFC 2850.

However, because of the broad range of meaning that it is possible to
ascribe to "oversight", we've lost track of that practice, and instead
without any explicit statement moved to an oversight practice that was
very different, and resulted in the current debacle.

>> Jon’s position at the time, after shouting expletives from the back
>> of the room was, “I am not going to publish a faulty specification
>> as an RFC.” It was notably the “I” word that stood out then as it
>> does now.
>> 
>> technical error, even if the process wasn’t well defined. And so
>> that did lead to a discussion about the IAB’s role in the process,
>> well prior to the Kobe Cabal and Boston Massacre; but in my memory,
>> neither Jon nor Bob wavered from their positions that they were
>> final arbiters over the series, though neither actively sought
>> confrontation with the IETF or the IAB, but instead sought to
>> facilitate the organization’s goals. The limits of the RFC Editor’s
>> authority has never really tested.
>>
> 

But (and I think this is an important part) being able to hire and fire
does not give a license to interpret oversight in a more invasive manner,
exemplified by the points about the rfcplusplus bof and the indications
of unhappiness with performance reflected in Heather's message
https://mailarchive.ietf.org/arch/msg/ietf/Qy8yFoM0AMcGOGEENxZ5BPrtsI4

I think we need to be clearer about the limits of "oversight", and
possibly also need to get rid of the term, if we mean to keep close to
the operation as it was before the last change of RSOC membership.

> stop using RFCs as the means of publishing IETF standards.

I read this as making the point that we need to be able to fire if we
can hire.  Agreed.  But I don't see it address the last year's operation
of the RSOC, which as far as I can see led to a very unwanted departure,
without an expressed need for or desire to fire.

Best regards,

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jul 2019 15:25:37 +1200

Hi Andrew,

Well, I would like to draw the discussion of what these various
documents mean to a close, since what matters now is how we go forward,
so I will comment briefly below but I hope we can agree to differ and
leave it there.

> 	1.  The RFC Editor in such a case would be terminated in that

Indeed, but that would be a binary result, and would indicate that
attempts at negotiation had failed.

> 	2.  That part of RFC 2850 would be shown to be inoperative.

I suspect that until the responsibility moved away from ISI, that might
well have been a real possibility.
 
> could call it. 

There we probably disagree, although my view is coloured by evidence that
both our "oversight" committees have in fact entered into details in a
way that I doubt was intended when they were set up. 

> And of course, if (2) is true then we are simply

That's correct, until the next NomCom cycle comes round.

> intended to mean "confirm", then that is at the very least unclear.

No, there is a difference as you point out. But there's nothing in the
RFC 2850 language that prompts the IAB to review its approval. At that
time the IETF had no revenue stream whatever, of course, and we were
entirely dependent on 3rd parties for all services. That made it 
difficult to be more specific.

> mind the past of a whole community.

Too true. I think I've already pointed out that I was one of the many who
didn't challenge the inclusion of "oversight" in RFC 5620 and RFC 6635.

...>>> digging) suggesting that the RSE is in fact subordinate to the IAB.
> hiring the contracted party, which is an obvious conflict of interest.

Yet clearly the collegial relationship with the RSE broke down.

> But how would one then decide on the search committee? 

TBD, because until very recently it seemed clear that the RSOC would
do that. I'd certainly argue that each of the RFC Streams should have 
a hand in populating the search committee. (I'm inclined to the view that
RSOC++ should itself be populated by the streams, not exclusively
by the IAB, but that deserves a new thread.)

Regards
    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Jul 2019 09:18:23 -0400

Hi,

Previous disclaimer as usual.

> in this case) can be read to mean a variety of things to different people.

My point is that the earlier documents didn't call this "oversight",
though at least one of them asserted that the IAB could remove the RFC
Editor.  Later, we built RFC Editor model 2; and despite various
claims to the contrary, I think it is utterly unfair to suggest that
was somehow the IAB arrogating power to itself.  The development of
version 2 took years and involved lots of consultation.  Under any
other circumstances it would have been an IETF stream document, in my
opinion, but it couldn't be for bureaucratic reasons.  That
development included the term "oversight", and as nearly as I can tell
the oversight model was a collegial one.  But it was still oversight,
as is appropriate when money is changing hands.  And if anyone
objected to the term at the time, I have not uncovered the objection,
though I admit I have not made an exhaustive search of all the
records.

> https://mailarchive.ietf.org/arch/msg/ietf/Qy8yFoM0AMcGOGEENxZ5BPrtsI4

I appreciate that there is a message in the archive that presents
someone's point of view about some events.  I will note that the IAB
and RSOC have been entirely consistent in refusing to talk about the
details from their point of view, for the simple reason that it's
incredibly bad practice to have a public discussion about an
individual contractor's performance (no matter how positive it might
be).  So, I think it is not justifiable for anyone not directly
involved in the events of the past months to comment on what did or
did not happen in that period, since the evidence is not available to
everyone (and can't be owing to the duty of confidentiality).
Therefore, I don't think it is reasonable to conclude that the
oversight was "invasive", whatever that would mean.  It appears
reasonable to conclude that the RFC Editor found the relationship
unpleasant in some way, since that's what she said.

> without an expressed need for or desire to fire.

Indeed, the expressed desire, available as public knowledge, was a
renewed engagement, which is why an offer to extend the contract was
offered.  I don't believe anyone was fired, though I know some people
interpreted the later re-bid plan as tantamount to firing.

My point was rather that, once another party has the ability to
determine whether I will continue in my employment, then that party
_by definition_ has some sway over how I undertake my work.  For the
party is always able to ask me to change my plans or risk losing my
employment.  In this sense, the party exercises oversight, and I am
having a very hard time understanding how the IETF is going to be in
the position to pay someone if the community doesn't acknowledge this
basic fact of the relationship.

Best regards,

A

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jul 2019 16:49:05 +0200

Hi Andrew,

> though I admit I have not made an exhaustive search of all the

And then the collegial oversight morphed into something else, recently.

And we didn't have any policy limitations in place to prevent that from
happening.

I believe that the power to hire and fire can (and sometimes should) be
separated, by fiat, from the power to direct the details of the activity
for which someone is hired.  This is essentially saying that there can be
separation between policy and detail management.  I believe that in the
relationship we are talking about, such a separation is essential for
effective operation, and for respectful co-operation.

Since we didn't have words in place earlier to express the limitation in
proper oversight such a separation would constitute, I believe we should
rectify that going forward.

> unpleasant in some way, since that's what she said.

You seem to argue for disregarding Heather's statement. I believe strongly
that the current situation came about because all was not well. 
Closing our eyes to the information available won't make that go away.

(And while it might be bad practice to have a public discussion about an
individual contractor's performance, it is quite as bad to use this as
an excuse not to scrutinize the performance of a body that I believe
ought to be answerable to the community for their actions.  I see a strong
resistance against such scrutiny, both from the IAB and the RSOC, and
I think the community is not well served by having the excuse you present
used to avoid such scrutiny.  I believe both RSOC and IAB could have
been much more forthcoming without straying into contractor performance
territory.)

I wish to look forward, but if we refuse to even consider the history that
led us to the current discussion, we will not learn from it, and will not
be able to improve things for the future.

> basic fact of the relationship.

Yes, it is true that anybody with the power to fire can always make any
request of the hired individual, with the threat of firing.  Since I believe
there are cases where exercising such power in the relationship we're
discussing would be detrimental, it's up to us to explicitly limit that
power in our policy describing the relationship.

I don't believe for a minute that it would be of any use at all to hire
someone, and then have a committee exercise micromanagement of all parts
of the work.  But you seem to argue that it is impossible to exclude that;
or at least seem unwilling to entertain the idea of a policy that would
place restrictions on the power to do so?  Or have I misunderstood?

Regards,

	Henrik

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 31 Jul 2019 11:10:27 -0400

Hi,

Still employed &c. &c.

> rectify that going forward.

It seems to me that this is actually exactly what the RSOC was
supposed to be.  It is the IAB that has the duty to recommend the
hiring and removal (the contract was, in the past, with ISOC and now
with IETF LLC).  The RSOC was an effort to insulate the RSE from the
IAB itself (and to provide a body whose membership was not tied to IAB
terms).  Are you suggesting we need a committee to oversee the
committee?

> You seem to argue for disregarding Heather's statement.

No, I argue that one should not assert too many things about what
happened in a particular case based only on necessarily partial
evidence.  The reality is that we do not and cannot have all the
different views, and only one of the parties involved is in a position
to talk about his or her view of what happened.  So it is better to
avoid the discussion of the particular and instead to devote our time
to discussing what is and is not wanted (and the principles of such
engagement, which is what I thought we were doing when we started
talking about the word "oversight").

> place restrictions on the power to do so?  Or have I misunderstood?

I think you have misunderstood, but I am not sure how to explain
myself more clearly.

A

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 31 Jul 2019 17:33:44 +0200

Hi Andrew,

> terms).  Are you suggesting we need a committee to oversee the

No.  I'm suggesting that we need explicit policy, words in a document, to
prevent any oversight body (using that name or any other) from directing
the work, rather than evaluating performance.

We need to put in place policy that restores the collegial relationship,
and protects the level of independence we desire.

> I think you have misunderstood, but I am not sure how to explain

Ok.

Regards,

	Henrik

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jul 2019 19:14:24 +0200

Beyond ranting, the obvious other thing to do:

Pithy summary -> [email-masked]
 This is the question i like nomcom to ask a candidate for IAB,
 This are the answers i think would best qualify a candidate IMHO.

Cheers
     Toerless

-- 
---
[email-masked]