Subject: RFC Editor model

From: Ted Hardie <[email-masked]>
Date: Mon, 24 Jun 2019 12:05:13 -0700

It's clear from Heather's message and the community discussion that there
remain some tensions among the various ways the RSE position fits into the
leadership.  The current RFC Editor model is an evolution from the one
which grew up under Jon, Joyce, and Bob's terms, and it reflects both the
need to have a strategic leader and the need to have a vehicle for both
employment and oversight.    The current model has a lot of moving parts,
some of which must treat the RSE in different lights.  Some aspects of the
tensions that can create are brought to light most clearly when
circumstances require us to consider a change.

Among those is a tension between the way the RSE is responsible to the
community as a community leader and as a paid member of the executive
staff.  In the first, we expect the RSE to respond to community input
directly, whether on mailing lists or on a plenary stage.  In the second,
the details of the contract (including terms, renewals, and pay) are
arranged between an RSE and the IASA (now the IETF LLC), but overseen by
the RSOC, whose recommendations go to the IAB for final decisions at
certain key points (e.g. appointment and renewal).

As an individual RSE grows in the role of community leader and is accepted
by the community on that basis, the tension between standard oversight of a
contract and the leadership position may get worse, as specific actions may
seem like challenges to the leadership of the incumbent rather than the
administration of a contract.

This may be a structural problem in the current model, and, if so,  the
community might see it again in any later RSE that either is or becomes
recognized as a community leader.

If others agree, the question becomes how to address it.  One option raised
by Sean Turner in the context of IASA2 discussions was making this an
employee position whose term is not limited; there are others as well.

As a practical matter, I do not believe that the time available allows the
IETF LLC to put out an RFP without referencing the current model.  But
during the community comments on the statement of work, I encourage others
to consider how flexible we can be within the confines of the current model
to enable an evolution to RFC Editor Model 3.  That may enable us to hire
an RSE with the view toward that evolution, as well as one dedicated to the
work for all of us which is consistent across the models:  producing an RFC
Series that serves the streams and the Internet technical community as best
we can.

My thoughts as individual only,

regards,

Ted Hardie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2019 15:15:01 -0400

I understood it to be the case from Heather’s perspective that the problem was not the administrative side of the process, but rather a sense that the RSOC was micromanaging and directing her as if it were they and not she who was responsible for deciding how the RSE should operate.

I don’t think that is in line with what the community wants.   I get the sense that Heather has been very responsive to the community in general, and that’s certainly been my experience in particular.

So the question to me is not how to adjust the process of putting out bids, but rather how to come to consensus on what, exactly, the community wants the RSE to do, or whether, in fact, the community has  a say in what the RSE does.

In the sense that you are talking about RSOC’s oversight role, it would seem to me that the role of the RSOC in terms of oversight would not be to autonomously determine how the RSE should function, but rather to serve as the community’s representative insofar as such representation is needed.

Does that make sense?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Jun 2019 22:54:47 +0200

Hi Ted,

Thank you for this note.  A few of us have strong feelings, as you mentioned.  You, Sarah and Heather have provided the community a lot of context.   It’s important for us to learn from experience, in a way that demonstrates deep respect for those who have contributed so much to our community, and I would support such a review..

Eliot

> On 24 Jun 2019, at 21:05, Ted Hardie <[email-masked]> wrote:
> 
> It's clear from Heather's message and the community discussion that there remain some tensions among the various ways the RSE position fits into the leadership.  The current RFC Editor model is an evolution from the one which grew up under Jon, Joyce, and Bob's terms, and it reflects both the need to have a strategic leader and the need to have a vehicle for both employment and oversight.    The current model has a lot of moving parts, some of which must treat the RSE in different lights.  Some aspects of the tensions that can create are brought to light most clearly when circumstances require us to consider a change.
> 
> Among those is a tension between the way the RSE is responsible to the community as a community leader and as a paid member of the executive staff.  In the first, we expect the RSE to respond to community input directly, whether on mailing lists or on a plenary stage.  In the second, the details of the contract (including terms, renewals, and pay) are arranged between an RSE and the IASA (now the IETF LLC), but overseen by the RSOC, whose recommendations go to the IAB for final decisions at certain key points (e.g. appointment and renewal).
> 
> As an individual RSE grows in the role of community leader and is accepted by the community on that basis, the tension between standard oversight of a contract and the leadership position may get worse, as specific actions may seem like challenges to the leadership of the incumbent rather than the administration of a contract.
> 
> This may be a structural problem in the current model, and, if so,  the community might see it again in any later RSE that either is or becomes recognized as a community leader.
> 
> If others agree, the question becomes how to address it.  One option raised by Sean Turner in the context of IASA2 discussions was making this an employee position whose term is not limited; there are others as well.
> 
> As a practical matter, I do not believe that the time available allows the IETF LLC to put out an RFP without referencing the current model.  But during the community comments on the statement of work, I encourage others to consider how flexible we can be within the confines of the current model to enable an evolution to RFC Editor Model 3.  That may enable us to hire an RSE with the view toward that evolution, as well as one dedicated to the work for all of us which is consistent across the models:  producing an RFC Series that serves the streams and the Internet technical community as best we can.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Jun 2019 21:58:08 +0100

Thanks for bringing this up Ted. I do think we need to get
community feedback on all this in the near term as we try
to find a new RSE.

I agree that you've described one aspect of tension with
the current RFC editor model. I'm sure there are more;-)

> employee position whose term is not limited; there are others as well.

FWIW, personally I don't like that employee idea at all for
reasons discussed on the iasa2 list. At least not with the
current RFC editor model - I think the community would have
to have first reached consensus on an RFC editor model 3 but
maybe that's what you meant.

> Series that serves the streams and the Internet technical community as best

I quite like the idea of hiring an RSE on the understanding
that the community will be developing an RFC editor model 3.
I'm not sure we can make other assumptions as to how that
discussion will end up in the near term though.

> My thoughts as individual only,

Ditto.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 10:14:56 -0400

Ted Hardie <[email-masked]> wrote:
    > If others agree, the question becomes how to address it.  One option
    > raised by Sean Turner in the context of IASA2 discussions was making
    > this an employee position whose term is not limited; there are others
    > as well.

I also wondered whether an employee / unlimited term would be better.
I think that we need to think about this a bit like a tenured professor.

    > As a practical matter, I do not believe that the time available allows
    > the IETF LLC to put out an RFP without referencing the current model.
    > But during the community comments on the statement of work, I encourage
    > others to consider how flexible we can be within the confines of the
    > current model to enable an evolution to RFC Editor Model 3.  That may
    > enable us to hire an RSE with the view toward that evolution, as well
    > as one dedicated to the work for all of us which is consistent across
    > the models: producing an RFC Series that serves the streams and the
    > Internet technical community as best we can.

I think that the community would be quite flexible to any well articulated
plan.  That doesn't mean we have to finish revising all the documents before
we start.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 10:18:02 -0400

> FWIW, personally I don't like that employee idea at all for reasons
    > discussed on the iasa2 list. At least not with the current RFC editor
    > model - I think the community would have to have first reached
    > consensus on an RFC editor model 3 but maybe that's what you meant.

What if the IETF were to support a position at a university, that was the RSE?
How would you feel about that?

(I'm not entirely sure how I feel about it yet, it just occured to me)

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Jun 2019 07:23:13 -0700

> I think that we need to think about this a bit like a tenured professor.

Echoing my question from the other thead: Why do you think that?  What
properties are you trying to achieve with that arrangement?

--Richard

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Jun 2019 09:27:49 -0500

On Tue, Jun 25, 2019 at 9:23 AM Richard Barnes <[email-masked]> wrote:

> On Tue, Jun 25, 2019 at 7:15 AM Michael Richardson <mcr+ietf@sandelman..ca
> <[email-masked]>> wrote:
>
>>

No way. IETF is not a university. That model does not stand.

I think that micromanaging mentioned in one of the mails above is a generic
problem in IETF. I believe most ADs micro manage  their WG chairs.
Maybe that should be addressed.

Regards,
Behcet

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jun 2019 16:31:14 +0200

> (I'm not entirely sure how I feel about it yet, it just occured to me)

Not a bad idea at all.
(Needs some more design, obviously.)
(Also, given that this was the way it went along for the first few decades…)

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jun 2019 07:32:37 -0700

> On Jun 25, 2019, at 7:27 AM, Behcet Sarikaya <[email-masked]> wrote:
> 
> On Tue, Jun 25, 2019 at 7:15 AM Michael Richardson <mcr+ietf@sandelman..ca <mailto:[email-masked]>> wrote:
> 
> Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> Echoing my question from the other thead: Why do you think that?  What properties are you trying to achieve with that arrangement?
> 
> 

Agreed. Closer to a judgeship, which is usually just called “lifetime appointment”.

RSE doesn’t need academic freedom; they might benefit from decoupling from politics. But as we in the US see, lifetime appointment doesn’t solve that either; it just concentrates the politics to the time of appointment and wires-in biases for decades.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Jun 2019 16:01:55 +0100

Hiya,

> (I'm not entirely sure how I feel about it yet, it just occured to me)

Assuming that it wasn't an appointment for life, or
a prof/chair-like position that a nominated university
chose the person to fill, then I don't see how that's
different from just appointing someone who happens to
be employed by a university to be the RSE via an RFP
according to the current process.

If it were a life-time appointment, or a prof/chair
position with the incumbent selected by a univ, then
I probably wouldn't like that on the basis that it'd
take away too much control from the community, but
it's hard to say really unless someone fleshed the
idea out some more.

Having an RSE that just happens to be an academic or
librarian could make sense of course but that's a
different question. It'd also make me wonder if the
RFC6635 statement that "The RSE is responsible for
the performance of the RFC Production Center and
Publisher" still made sense for such an RSE, so again
I'd fall back to preferring we first understand if we
have a community position on what we all want for
the RSE role, be that an "RFC editor model 3" or what
we have today.

Cheers,
S.

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jun 2019 08:08:53 -0700

> On Jun 25, 2019, at 8:01 AM, Stephen Farrell <[email-masked]> wrote:
> 

A lifetime position means they *can* act without fear of reprisal.
(whether they do or not is quite different)

Not everyone who works at a university is in the tenure track, in fact most are not  (instructors, research faculty, staff, not to mention grad students).

That goes for most people who actually teach at universities too (many of which aren’t even full-time).

And even tenured faculty can lose contracts in ways that tenure has no influence. 

Joe

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Jun 2019 08:33:50 -0700

On Tue, Jun 25, 2019 at 8:01 AM Stephen Farrell <[email-masked]>
wrote:

> "The RSE is responsible for the performance of the RFC Production Center
> and Publisher"
>

The task would look a lot different, honestly, if that part were separated
out, and it may be that the community should consider a separation there.
It is difficult to be certain, since the large number of other touch points
with the current RPC's organization (AMS) may color our thinking, but
making this more directly coupled to the LLC as a contracting authority or
the stream managers might be a good structural change.

regards,

Ted

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Jun 2019 09:15:56 -0700

On Jun 25, 2019, at 8:33 AM, Ted Hardie <[email-masked]> wrote:

>> On Tue, Jun 25, 2019 at 8:01 AM Stephen Farrell <[email-masked]> wrote:
>> "The RSE is responsible for the performance of the RFC Production Center and Publisher" 
> 
> The task would look a lot different, honestly, if that part were separated out, and it may be that the community should consider a separation there.  It is difficult to be certain, since the large number of other touch points with the current RPC's organization (AMS) may color our thinking, but making this more directly coupled to the LLC as a contracting authority or the stream managers might be a good structural change

Yes. That's became pretty obvious to me after working just a few months with the RSOC. In the current structure the RSE is supposedly accountable for the RFC production center, yet has no way to actually manage it. Separating that clearly would remove a big source of stress.

The other source of stress is the independent series. I do believe and so many times that this streams provides useful checks and balance against the IESG. It is clearly a source of tension, but that tension should be assumed and managed. 

The question then is, what is left for the RSE. The RFC Editor report is all about the RPC work. What would it contain if the RSE did not formally manage the RPC? Would the bulk of the RSE work evaporate? I think not. 

The RSE could actually focus on the series evolution, and there is plenty to do there. For example, we are using a bespoke format in the name of accessibility and long term archival, but it requires specialized personnel and tools which more than double production costs compared to other organizations.

We are also handling code snippets and abstract language specifications by including them in our specs. Do this code objects require the same management as specification texts? What about bug fixes?

We inherited a structure in which RFC  are immutable. This leads to the errata process and long cycles of updates by WG processes. Is that the best we can do?

We hold the RFC series in great veneration, but we cannot answer simple questions like who reads it, what is their impact. How can we manage change without data about our results?

I would like to see the RSE focus on such questions. And I think removing the RPC management and the ISE tension from the role would help that.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 25 Jun 2019 12:14:16 -0500

Top-posting to call attention to the most important question in Christian's
email - "is that the best we can do?" It appeared as part of one paragraph,
but seems broadly applicable to all his other questions.

I might have opinions about his other questions, and all our opinions might
be worth talking about, but I think talking about how much the community is
willing to consider changing, would be a good first step, no matter what
direction we decided to go.

Spencer

On Tue, Jun 25, 2019 at 11:16 AM Christian Huitema <[email-masked]>
wrote:

> the stream managers might be a good structural change
>
>
> Yes. That's became pretty obvious to me after working just a few months
> with the RSOC. In the current structure the RSE is supposedly accountable
> for the RFC production center, yet has no way to actually manage it.
> Separating that clearly would remove a big source of stress.
>
> The other source of stress is the independent series. I do believe and so
> many times that this streams provides useful checks and balance against the
> IESG. It is clearly a source of tension, but that tension should be assumed
> and managed.
>
> The question then is, what is left for the RSE. The RFC Editor report is
> all about the RPC work. What would it contain if the RSE did not formally
> manage the RPC? Would the bulk of the RSE work evaporate? I think not.
>
> The RSE could actually focus on the series evolution, and there is plenty
> to do there. For example, we are using a bespoke format in the name of
> accessibility and long term archival, but it requires specialized personnel
> and tools which more than double production costs compared to other
> organizations.
>
> We are also handling code snippets and abstract language specifications by
> including them in our specs. Do this code objects require the same
> management as specification texts? What about bug fixes?
>
> We inherited a structure in which RFC  are immutable. This leads to the
> errata process and long cycles of updates by WG processes. Is that the best
> we can do?
>
> We hold the RFC series in great veneration, but we cannot answer simple
> questions like who reads it, what is their impact. How can we manage change
> without data about our results?
>
> I would like to see the RSE focus on such questions. And I think removing
> the RPC management and the ISE tension from the role would help that.
>
> -- Christian Huitema
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Jun 2019 18:21:54 +0100

Hi Christian,

Snipping to just one part of your mail.

> The other source of stress is the independent series. I do believe

> and so many times that this streams provides useful checks and 

> balance against the IESG. It is clearly a source of tension, but that

> tension should be assumed and managed. 

Thank you for your support of the Independent Submissions stream.

It would be unsurprising if any technical work related to the Internet was without its tensions. And given that one of the reasons for the stream’s existence is publish things that the IETF and/or the IESG has chosen to not publish, I am sure there are specific tensions.

It is sad, however, that these concerns are not brought to the Independent Submissions Editor for discussion. Some tensions can be handled by reconciling the differences between perceptions and the situation on the ground. I did talk with the IESG at IETF-102 (the slides are available at http://www.olddog.co.uk/ise-iesg-ietf102.pdf), but have had only passing conversations with anyone on the IAB.

It is disappointing that RSOC has not spoken with me since I took up the office in March 2018.

While it is in the nature of the role that I am largely unsupervised (just being appointed or replaced by the IAB), it is good to talk!

And…

> I would like to see the RSE focus on such questions. And I

> think removing the RPC management and the ISE tension

> from the role would help that.

Removing the tension would be good.

But, it is pretty clear that Independent Submission RFCs are RFCs. Therefore their publication comes under the care of the RSE. 

Best,

Adrian

--

Adrian Farrel

Independent Submissions Editor (ISE)

[email-masked]

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Jun 2019 10:54:16 -0700

Christian,

> On Jun 25, 2019, at 9:15 AM, Christian Huitema <[email-masked]> wrote:
> 
> 

This, so called “stress” is largely independent of the RSE.  That’s why there is an Independent Series Editor (see RFC 6548).  This is largely independent of the RSE.   I don’t see the RSE’s involvement to be significant.   The tension is between the ISE and the IESG.

> I would like to see the RSE focus on such questions. And I think removing the RPC management and the ISE tension from the role would help that.

These are all fine questions and ones which I too would like to see the RSE look at.  This is the main part of the RSE's job, that is, the evolution of the RFC Series.  It’s very unfortunate that the IAB choose a course of action that was taken by the current RSE as vote of no confidence.   

While we are talking about changes, we should also be talking about should the IAB continue in its current role with the RFC series.  With this event, and things like the RFC++ BOF, I am wondering if the IAB should continue in its current role regarding the RFC Editor and Series.

Bob

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2019 14:02:15 -0400

On 6/25/19 12:15 PM, Christian Huitema wrote:

> We inherited a structure in which RFC  are immutable. This leads to 
> the errata process and long cycles of updates by WG processes. Is that 
> the best we can do?

I have many times observed the value in RFCs being immutable - e.g. as 
prior art in patent cases (which actually improves the ability of the 
public to use our protocol standards) and to minimize confusion between 
versions (if you're quoting RFC XXXX for some particular XXXX it means 
the same thing to everybody, rather than having to also cite a date or 
version).

I believe having RFCs be immutable also discourages churn and makes our 
product more stable by discouraging participants from fighting the same 
battles forever.

(It doesn't prevent that entirely of course, and I've been distressed 
more than once to see a working group task with revising an old RFC used 
as an opportunity to invalidate good work done years earlier, not for 
sound technical reasons but simply because some people didn't like it or 
it didn't suit their politics.)

Mostly I think having RFCs be immutable is the right choice. That's not 
to say that there's no room for improvement at all.   I could see a 
model where the specifications are living documents and the RFCs are 
snapshots of those documents at particular points in time that have been 
subject to thorough community review.   But it would take a lot of 
rethinking of our process to make that work well, and we could easily 
end up with a result that's far worse than what we have.

If I were making an ordered list of which IETF problems need the most 
attention, this would be very far down on the list.   I'm much more 
concerned, for instance, with the growing tendency of "IETF" (in the 
broad sense) to fragment into separate organizations that each see 
different self-interests, and the consequent danger of friction between 
these organizations to work at cross-purposes with IETF's broader mission.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Jun 2019 19:27:17 +0100

Hiya,

On 25/06/2019 18:21, Adrian Farrel wrote:
> It is sad, however, that these concerns are not brought to the
> Independent Submissions Editor for discussion. Some tensions can be
> handled by reconciling the differences between perceptions and the
> situation on the ground. I did talk with the IESG at IETF-102 (the
> slides are available at
> http://www.olddog.co.uk/ise-iesg-ietf102.pdf), but have had only
> passing conversations with anyone on the IAB.
Nice slides. I agree you are not a problem:-)

FWIW, I think discussion of the RFC editor model will
be much more tractable and likely to result in a result
(be that change or status-quo) if we don't as part of
this delve into (im)perfection of the types of RFC, WTF
Updates means?, etc.

For me, that'd definitely include *not* reconsidering
the existence of the ISE but just valuing the ISE's
input to the discussion as one of stream owners.

Or, we can of course each pick a tiny wee ocean and
individually attempt to get that to the boil...

Cheers,
S.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jun 2019 18:38:11 +0000

> I have many times observed the value in RFCs being immutable - e.g. as prior art in patent cases (which actually improves the ability of the public to use our protocol standards) and to minimize confusion between versions (if you're quoting RFC XXXX for some particular XXXX it means the same thing to everybody, rather than having to also cite a date or version).

Regarding erratum, though a formal process exists to review and publish errata exists, it seems to be of little effect, as few observe, much less are even aware, such exists, despite the text in the boilerplate on the first page and the link at the top of each RFC's  tools.ietf.org <http://tools.ietf.org/> page.   Experience/opinions may vary on this point.

I sometimes wonder if a lightweight errata-driven republication of RFCs, whereby the "latest" is displayed by default, wouldn't be better.  Yes, this leads to versions, such as RFC XXXX.[0-9]*, but why is this a problem or, rather, how is it any worse than current?   The "displaying the latest by default" behavior may be limited to just the tools page, but that being the primary access point seems like a lot of goodness to me.

PS: I agree that this is low-priority relative to other items being discussed, but wanted to mention it while the door was open.

Kent

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Jun 2019 19:46:39 +0100

On 25/06/2019 19:38, Kent Watsen wrote:
>>> the errata process and long cycles of updates by WG processes. Is 
>>> that the best we can do?
>>
>> public to use our protocol standards) and to minimize confusion 
>> between versions (if you're quoting RFC XXXX for some particular XXXX 
>> it means the same thing to everybody, rather than having to also cite 
>> a date or version).
> 
> Regarding erratum, though a formal process exists to review and publish 
> errata exists, it seems to be of little effect, as few observe, much 
> less are even aware, such exists, despite the text in the boilerplate on 
> the first page and the link at the top of each RFC's tools.ietf.org 
> <http://tools.ietf.org> page.   Experience/opinions may vary on this point.
> 
> I sometimes wonder if a lightweight errata-driven republication of RFCs, 
> whereby the "latest" is displayed by default, wouldn't be better.  Yes, 
> this leads to versions, such as RFC XXXX.[0-9]*, but why is this a 
> problem or, rather, how is it any worse than current?   The "displaying 
> the latest by default" behavior may be limited to just the tools page, 
> but that being the primary access point seems like a lot of goodness to me.
> 
> PS: I agree that this is low-priority relative to other items being 
> discussed, but wanted to mention it while the door was open.
> 
> Kent
> 

That is a good idea and provides better change control since you ought 
to be able to establish which errata were implemented whereas at the 
moment there is no short hand way to specify that.

- Stewart

---

From: Michael StJohns <[email-masked]>
Date: Tue, 25 Jun 2019 14:46:50 -0400

> maybe that's what you meant.
To echo this - having the RSE as an employee is a terrible idea.   In 
the US at least, the main difference between an employee and a 
contractor is that you can tell the contractor what to do (at least 
within the constraints of the contract SOW), but not how to do it.  An 
employee can be micromanaged to within an inch of their life.

I don't think I want to have trust future LLC/IAB/RSOC members to 
understand and honor the need for independence of the RSE process if the 
RSE were to become an employee,  especially given the current set of issues.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 25 Jun 2019 14:55:41 -0400

On 6/25/2019 2:38 PM, Kent Watsen wrote:
>
>
> I sometimes wonder if a lightweight errata-driven republication of 
> RFCs, whereby the "latest" is displayed by default, wouldn't be 
> better.  Yes, this leads to versions, such as RFC XXXX.[0-9]*, but why 
> is this a problem or, rather, how is it any worse than current?   The 
> "displaying the latest by default" behavior may be limited to just the 
> tools page, but that being the primary access point seems like a lot 
> of goodness to me.

This is both a tools and production cost.  Tools to maintain the N side 
copies, and production in the form of editing and release. While errata 
tend to be small, there is still some effort in finding the source for 
the document, making the changes, confirming the changes with the 
authors and with the errata reporter.

I don't think this meets even the loosest definition of "cost effective".

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Jun 2019 20:57:23 +0200

> On 25 Jun 2019, at 20:27, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I agree.  Figuring out how to structure the role of the RFC Editor role for success in our evolving environment seems enough to be getting on with.  And I wouldn’t rush this.  Better to take some time to get it right.  And there are a great many questions to answer, I would imagine.

Also, the great Will Rogers used to say, “Things ain't what they used to be and probably never was.”  Not everything was perfect when Jon and Bob held the pen and were largely accountable only to themselves.  A few of us have our stories…. That’s partly why we have the accountability structure we have today.

> input to the discussion as one of stream owners.

+1 to this.  I believe the community had its say about this last year.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 25 Jun 2019 15:02:26 -0400

Hi Kent,

> On Jun 25, 2019, at 2:38 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> 

The tools team is supporting a project similar to this, still in development/testing phase: https://github.com/ietf-tools/Rfc-Errata <https://github.com/ietf-tools/Rfc-Errata>

Alissa

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Jun 2019 20:05:12 +0100

> I don't think this meets even the loosest definition of "cost effective".

I think that depends on how much is spent dealing with the cost of two 
incompatible implementations.

- Stewart

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2019 15:30:10 -0400

On 6/25/19 2:38 PM, Kent Watsen wrote:
>> I have many times observed the value in RFCs being immutable - e.g. 
>> as prior art in patent cases (which actually improves the ability of 
>> the public to use our protocol standards) and to minimize confusion 
> Regarding erratum, though a formal process exists to review and 
> publish errata exists, it seems to be of little effect, as few 
> observe, much less are even aware, such exists, despite the text in 
> the boilerplate on the first page and the link at the top of each 
> RFC's tools.ietf.org <http://tools.ietf.org> page. Experience/opinions 
> may vary on this point.
>

It sounds like a disaster to me.    I've lost too much hair trying to 
deal with people working at a distance, and using different versions of 
a specification.   Perhaps the errata could be made more visible.   But 
I find it much better to have separate errata than to have have late 
changes buried in the text of a specification.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jun 2019 21:56:02 +0200

Hi Spencer,

> On Jun 25, 2019, at 19:14, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> how much the community is willing to consider changing

I’m not sure I read this correctly (is this about the community changing and getting rid of its badness?  Probably more about the community changing the model.), but I have a long-standing observation here:

We appear to be too tinker-happy in this space.

50 years of RFCs is an asset that the IETF can avail itself of.
(I’m definitely not saying “has”, but we can make good use of it.)

What I’ve seen in the last couple of years is a textbook example of action bias.
(For some reason, English Wikipedia doesn’t seem to discuss this concept, so right now I only can offer https://de.wikipedia.org/wiki/Action_Bias to those are not familiar with the concept.)

Grüße, Carsten

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Jun 2019 13:38:44 -0700

On Tue, Jun 25, 2019 at 11:56 AM Michael StJohns <[email-masked]>
wrote:

> copies, and production in the form of editing and release.

Funny how there are off-the-shelf tools for managing such small changes,
which engineers use all the time.  (And so do lawyers!)

--Richard

> While errata

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2019 16:52:27 -0400

+1

On 6/25/19 3:56 PM, Carsten Bormann wrote:

> (For some reason, English Wikipedia doesn’t seem to discuss this concept, so right now I only can offerhttps://de.wikipedia.org/wiki/Action_Bias  to those are not familiar with the concept.)

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2019 16:52:34 -0400

+1

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 21:02:19 -0400

Richard Barnes <[email-masked]> wrote:
    >> Ted Hardie <[email-masked]> wrote: > If others agree, the question
    >> becomes how to address it.  One option > raised by Sean Turner in the
    >> context of IASA2 discussions was making > this an employee position
    >> whose term is not limited; there are others > as well.
    >>

    > properties are you trying to achieve with that arrangement?

Tenured professors could historically never be dismissed for what they
say/researched/etc.  That's imprecise, and I looked around for a better
definition, but it varies quite a lot by country, and has mutated a lot in
the last twenty years.  (Two of my three parents were tenured professors)

Being tenured doesn't guarantee a good teaching schedule, a high salary,
research funding, or serving on important committees!  Tenured professors
still undergo evaluation, but except for pretty serious things (usually
criminal), dismissal does not result.  I understood it started in the UK to
protect academics from the wrath of the monarch.  There is famous story about
Isaac Asimov https://en.wikipedia.org/wiki/Isaac_Asimov, [48][49][50].

Being tenured means that it is possible to disagree strongly about how things
should get done without fearing being dismissed.   It really feels like this
is what the RSE needs.  I think it is notable that Postel/etc. essentially
had this kind of security via ISI.

I think it is also important to recognize that the RSE isn't the RFC
Publication Centre.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Jun 2019 20:04:15 -0700

> had this kind of security via ISI.

What I'm pushing on here is why there's a need for the RSE to have this
level of protection.  It seems to envision a scenario where all of the
NOMCOM-appointed, nominally community-endorsed forces are arrayed against
this individual, and they are the last thing preventing some bad thing from
happening.  Otherwise, it would make sense for some body to be able to
override them, by force of dismissal if necessary.  Is that what you have
in mind?

--RLB

---

From: Daniel Karrenberg <[email-masked]>
Date: Wed, 26 Jun 2019 10:23:29 +0200

> On 25. Jun 2019, at 21:56, Carsten Bormann <[email-masked]> wrote:
> 
> ...
> ...
> ...

Special-purpose committees also appear to be specially tinker-happy. Have we created too many of those?

---
Sent from a handheld device.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Jun 2019 11:18:38 +0100

> Special-purpose committees also appear to be specially tinker-happy. Have we created too many of those?

We should have a committee to oversee the creation of special-purpose committees, and another to regulate tinkering.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 26 Jun 2019 07:17:39 -0400

On Wed, Jun 26, 2019 at 6:19 AM Adrian Farrel <[email-masked]> wrote:

> We should have a committee to oversee the creation of special-purpose
> committees, and another to regulate tinkering.
>

It's the only way to have proper separation of powers!

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 09:38:20 -0400

Richard Barnes <[email-masked]> wrote:
    >> Being tenured means that it is possible to disagree strongly about how
    >> things should get done without fearing being dismissed.  It really
    >> feels like this is what the RSE needs.  I think it is notable that
    >> Postel/etc. essentially had this kind of security via ISI.
    >>

    > NOMCOM-appointed, nominally community-endorsed forces are arrayed
    > against this individual, and they are the last thing preventing some
    > bad thing from happening.  Otherwise, it would make sense for some body
    > to be able to override them, by force of dismissal if necessary.  Is
    > that what you have in mind?

a) The IESG can decide to publish the STD/FYI/BCP series elsewhere.
b) It seems that we've seen the situation you describe just now.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 26 Jun 2019 09:50:35 -0400

> a) The IESG can decide to publish the STD/FYI/BCP series elsewhere.

I think we agree that this would be an undesirable outcome.

> b) It seems that we've seen the situation you describe just now.

I'm missing your allusion here.  Elaborate?

--Richard

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 11:20:16 -0400

Richard Barnes <[email-masked]>'s MUA mangled the quoted text, and I don't feel like
>     >> Postel/etc. essentially had this kind of security via ISI.

mcr> b) It seems that we've seen the situation you describe just now.

rb> I'm missing your allusion here.  Elaborate?

Yes, you said it:

rb> It seems to envision a scenario where all of the NOMCOM-appointed,
rb> nominally community-endorsed forces are arrayed against this individual,
rb> and they are the last thing preventing some bad thing from happening.

I am claiming that some think that this situation has just occured, and it
resulted in the RSE deciding to do something else rather than attempt to
continue fighting against some bad thing happening.
(I am not saying that I even understand what the "thing" was, or agree that
it was "bad")

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jun 2019 14:29:31 -0500

By way of disclosure, I'll be the first to point out that I'm on both 
the IESG and the RSOC, and so I'm going to have a certain perspective on 
the events underway. I hope that my statements below stand on their own, 
independently of whatever interests my position may imply.

> (I am not saying that I even understand what the "thing" was, or agree that

You or anyone else for that matter. What happened is:

 1. We, the community, liked Heather personally
 2. Heather is leaving
 3. So we're sad [1]

You're kind of pointing sideways at some conspiracy theories that people 
have come up with to explain why #2 happened, but they're not really 
supported by facts in evidence. This is natural: because of #3, it's 
understandable to try to find someone to blame. But this is why you're 
having a hard time understanding what the "thing" is: it's whatever 
boogeyman the conspiracy theorists have chosen to invent for that 
moment. And so it's definitely "bad", but it isn't actually "real".

I'm not saying that all of the critical posts on this topic are wrong. 
There are some valid points being made about the overall RFC Editor 
model, its history, and where its future may lie; and some of these are 
necessarily being couched as criticism.

But there is also some poorly motivated rage being expressed based on 
wholly fabricated assumptions, much of which seems to be impervious to 
facts and unable to cite sources. Again, this is an understandable and 
natural reaction to being sad, although it is far from helpful. Even 
worse, it may harm our ability to find a suitable replacement for 
Heather: who wants to walk into a community full of rage?

And so I strongly encourage you -- and others -- to be wary of arguments 
based on supposition. Share what you know and think, but please don't 
amplify untested theories.

/a

____
[1] I'm using "sad" here as a proxy for a complicated maelstrom of 
negative emotions that people seem to be undergoing at the moment. 
There's probably an entire doctoral thesis's worth of explanation that 
could be used to describe these emotions more accurately, but I don't 
have the tools to do so.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 26 Jun 2019 15:41:11 -0400

Wow - just wow.

On 6/26/2019 3:29 PM, Adam Roach wrote:
> the IESG and the RSOC, and so I'm going to have a certain perspective 
> on the events underway. I hope that my statements below stand on their 
> own, independently of whatever interests my position may imply.
>
What a piece of self serving revisionism.    What appears to have really 
happened from the emails that have been published is:

1) We the RSOC like Heather personally (or so the RSOC has said repeatedly).

2) Because of this the RSOC decided we needed to recompete the RSE and 
used the excuse of needing to tweek the RFP process - said process that 
could have been delayed for almost 3 years but was considered by the 
RSOC to be of critical importantance (why?) that the RSE just did it now.

3) Because of the short time to do so the RSOC grudgingly offered to 
extend the current RSE contract through the end of 2021 and notified her 
of the intent to terminate the contract at that point.

4) At some point near the time Heather was notified, the RSOC sent a 
note to the IAB indicating (2) and (3), which Heather would have read.

5) Heather, analyzing both what has been said and not said declined the 
extension for the reasons she stated.

6) Some of us are sad, and I'm not sure of who that includes.

> 1.
>
>
> You're kind of pointing sideways at some conspiracy theories that 
> people have come up with to explain why #2 happened, but they're not 
> really supported by facts in evidence. This is natural: because of #3, 
> it's understandable to try to find someone to blame. But this is why 
> you're having a hard time understanding what the "thing" is: it's 
> whatever boogeyman the conspiracy theorists have chosen to invent for 
> that moment. And so it's definitely "bad", but it isn't actually "real".
>
> model, its history, and where its future may lie; and some of these 
> are necessarily being couched as criticism.
>
> And so I strongly encourage you -- and others -- to be wary of 
> arguments based on supposition. Share what you know and think, but 
> please don't amplify untested theories.
>
> /a
>
> ____

---

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Jun 2019 16:17:43 -0400

Adam,

OK - I’ll bite - since you are a member of the committee that did the deed (so to speak) 
please tell us exactly why did the committee (and you) decide it was the time to truncate the contract early

as others have pointed out - even with the plan as it seems to have been decided the work would 
be done by a future RSOC - why not let the future RSOC decided on its own what it wanted to do 
instead of binding it to the plan of the current RSOC?

Scott

> On Jun 26, 2019, at 3:29 PM, Adam Roach <[email-masked]> wrote:
> 
> By way of disclosure, I'll be the first to point out that I'm on both the IESG and the RSOC, and so I'm going to have a certain perspective on the events underway. I hope that my statements below stand on their own, independently of whatever interests my position may imply.
> 
> 	• We, the community, liked Heather personally
> 	• Heather is leaving
> 	• So we're sad [1]
> 
> 
> You're kind of pointing sideways at some conspiracy theories that people have come up with to explain why #2 happened, but they're not really supported by facts in evidence. This is natural: because of #3, it's understandable to try to find someone to blame. But this is why you're having a hard time understanding what the "thing" is: it's whatever boogeyman the conspiracy theorists have chosen to invent for that moment. And so it's definitely "bad", but it isn't actually "real".
> 
> I'm not saying that all of the critical posts on this topic are wrong. There are some valid points being made about the overall RFC Editor model, its history, and where its future may lie; and some of these are necessarily being couched as criticism.
> 
> But there is also some poorly motivated rage being expressed based on wholly fabricated assumptions, much of which seems to be impervious to facts and unable to cite sources. Again, this is an understandable and natural reaction to being sad, although it is far from helpful. Even worse, it may harm our ability to find a suitable replacement for Heather: who wants to walk into a community full of rage?
> 
> And so I strongly encourage you -- and others -- to be wary of arguments based on supposition. Share what you know and think, but please don't amplify untested theories.
> 
> /a
> 
> ____
> [1] I'm using "sad" here as a proxy for a complicated maelstrom of negative emotions that people seem to be undergoing at the moment. There's probably an entire doctoral thesis's worth of explanation that could be used to describe these emotions more accurately, but I don't have the tools to do so.
>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Wed, 26 Jun 2019 14:45:52 -0600

This language is not professional or respectful, and we urge careful
consideration in future replies.  Disputing one's view of events is of
course welcome; insinuation that others are speaking or acting in bad
faith is not.

-
IETF Sergeant at Arms

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2019 16:50:45 -0400

Matthew, with respect, what Adam said was also quite disrespectful, just more subtly so. Not that two wrongs make a right—they do not. But consistency is a virtue. 

Sent from my iPhone

> On Jun 26, 2019, at 4:45 PM, Matthew A. Miller <[email-masked]> wrote:
>

---

From: Mary B <[email-masked]>
Date: Wed, 26 Jun 2019 16:09:42 -0500

I agree with Ted and Mike's assessment actually.

Mary.

On Wed, Jun 26, 2019 at 3:51 PM Ted Lemon <[email-masked]> wrote:

> Matthew, with respect, what Adam said was also quite disrespectful, just
> more subtly so. Not that two wrongs make a right—they do not. But
> consistency is a virtue.
>
> Sent from my iPhone
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jun 2019 16:11:58 -0500

Yes, and I have been admonished off-list. I apologize for the 
implication that unnamed others are participating in this conversation 
in bad faith.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jun 2019 16:13:46 -0500

Sarah explained the contract question already:

https://mailarchive.ietf.org/arch/msg/ietf/IdUciHW3pdluk1m2pYaqk9JCj4c

I have nothing to add to her explanation, as there's really no more 
substantive detail regarding the contract than what she already included.

To your second query: I will point out that planning takes time, and no 
one wanted to rush the process.

/a

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 26 Jun 2019 17:28:00 -0400

On Wed, Jun 26, 2019 at 04:13:46PM -0500, Adam Roach wrote:
> To your second query: I will point out that planning takes time, and no one
> wanted to rush the process.

That doesn't seem to be a terribly substative answer to the question,
why the decision had to be made in 2019, whether to put the contract
back out to bid in 2021, versus 2023?

Could you perhaps add more substance to enlighten that particular
aspect of this issue?

						- Ted

---

From: Sarah Banks <[email-masked]>
Date: Wed, 26 Jun 2019 15:45:59 -0600

Michael,
	Please see inline. I’ve snipped, because scrolling pages annoys me. :)

Thanks
Sarah
> 1) We the RSOC like Heather personally (or so the RSOC has said repeatedly).
SB// I don’t believe the RSOC has made a comment one way or another about “liking” Heather. The RSOC’s job isn’t to like someone - or dislike someone - it was to perform the IAB-delegated task of oversight. I think what you’re getting at is the part of my note that said that we wanted to bid the contract again, and that we were indicated that doing so was NOT a comment on Heather’s performance. That remains the case, as stated.

> 2) Because of this the RSOC decided we needed to recompete the RSE and used the excuse of needing to tweek the RFP process - said process that could have been delayed for almost 3 years but was considered by the RSOC to be of critical importantance (why?) that the RSE just did it now.
> 

SB// I’m trying to understand why the RSOC is being belittled like this. Help me understand. We don’t need an excuse. The IAB doesn't need an excuse to reseat the RSOC - we serve at their pleasure. The contract doesn’t need “an excuse” to be extended, or not, for up to 2 additional times after being awarded; there’s nothing in 6635 that states we need a reason. One would assume there’d be one; one might even hope there’d be one, and one should certainly expect a conversation about it. I’ve also answered the “why” portion of your question. The RSOC was concerned that the last time we went to bid, there was only 1 respondent. And while I am not trying to bring Heather into this, one of the things I deeply admired about her comportment was that she too brought this up as a point of concern. The RSOC, the IAB, indeed most of the IETF “leadership” (for lack of a better term) is comprised of volunteers. We have day jobs. Even in our day jobs when you get into executing big processes, the timeline can get away from you. Here, because there was a decent level of unknown raised by the new RSOC, we decided to run through the process early. 
> 3) Because of the short time to do so the RSOC grudgingly offered to extend the current RSE contract through the end of 2021 and notified her of the intent to terminate the contract at that point.
> 

SB// “Grudgingly” - where does that characterization come from? Help me understand. We didn’t enter this lightly. We were concerned that bidding the contract again would be construed as something other than where we landed; but no one said terminate. No where in my language, in the RSOC language, actually, of our discussions, was the word “terminate” used. I can’t speak for other’s intents and motivations, and consensus doesn’t always mean every one agreed, but the RSOC never recommended terminating the contract. As was previously stated at some point on this very, very long thread, there is nothing that barred the current RSE from bidding for the job again. I’m human, all members of the RSOC are human, so I accept that we might have better worded our recommendation. If that’s your position, please, send me the language, and I’d be happy to review with the RSOC and note where we can improve. 
> 4) At some point near the time Heather was notified, the RSOC sent a note to the IAB indicating (2) and (3), which Heather would have read.
> 
SB// Just to be pedantic, we did not send a note to the IAB with 2 and 3; we sent the note, which Ted has now shared as part of the IAB minutes, recommending to extend, and then rebid, to refine the process that some felt was not executed well the first time. 

> 5) Heather, analyzing both what has been said and not said declined the extension for the reasons she stated.
> 
SB// Heather has sent 2 notes to the list on her reasons. If there’s any confusion here, I suggest re-reading them. 
> 6) Some of us are sad, and I'm not sure of who that includes.
SB// Speaking for myself, I am extremely disappointed and sad that she is leaving, particularly in this way. I am very sad she’s felt the way she has, and I sincerely hope that this doesn’t change the amount of positive and grateful feedback the community has sent in the middle of all of this, or cast a shadow on the actual work she’s delivered as RSE. We knew when we made the recommendation that this outcome was a potential risk. Unfortunately, I don’t have the skills to rewind this clock and undo all of the pieces that got us here. But I’ll also state this, from my own personal perspective. The notion that the RSOC recommendation alone is what prompted Heather to not reup her contract is absurd. Evidence? Heather’s 2 notes make that clear. My own personal experience with Heather is that she has not shown herself to be impulsive; she’s also shown herself to take the longevity of the role of RSE seriously, both in her views of the RFC Series and longevity, as well as the RSE role herself. All of that leads me to say again - the notion that the RSOC made a recommendation to extend the contract 1 year and then rebid - this notion alone would be why Heather would not stay on as RSE doesn’t hold water. 

SB// Finally, I’ve seen some wonderful points and concerns and potential next steps come out of this. I sincerely hope that we as a community can continue to make progress in that lane. Examine what went “wrong” (could be refined, changed, made better, etc), decide where we want to go, and then take the transparent steps to get there.

</2 cents>
Sarah

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Jun 2019 16:59:49 -0500

> Could you perhaps add more substance to enlighten that particular

Sarah has again beaten me to it:

https://mailarchive.ietf.org/arch/msg/ietf/rsfsZmG4yRkUv_sUUaGXGPxzNE4

/a

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Jun 2019 00:09:01 +0200

On Jun 26, 2019, at 23:45, Sarah Banks <[email-masked]> wrote:
> 
> The notion that the RSOC recommendation alone is what prompted Heather to not reup her contract is absurd.

I’d probably lose interest in this thread less quickly if we could suspend examining this tiny part of the picture and return to the bigger picture — what was it that made the position of the RSE less tenable for this particular incumbent than it might have been, and do we want to address this and/or our expectations of the RSE’s job and the RFC publication series as a whole.

Grüße, Carsten

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2019 15:25:10 -0700

from my pov, this discussion repeatedly descends to details of
contracts, process arcana, and other symptoms of the corporitization of
the ietf; while what we have done in reality is turn one of the mcentral
and most respected pillars of our culture into crass work for hire which
a person of talent and integrity would decline.  and one did.

the rfc++ bof, though it started in secret, at least came out in the
open in time to be discussed by the community and stopped.  the current
mess, which smells of a redux, stayed secret until there are only dead
bodies, beyond resuscitation.

so all we have left is trying to fix the process; when what we really
need is stewardship, integrity, and a real sense that we are here for
what used to be a shared vision of the internet.

randy

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 26 Jun 2019 18:52:03 -0400

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

With respect, that doesn't seem terribly responsive.  The best I can
find in that message is:

   Here, because there was a decent level of unknown raised by the new
   RSOC, we decided to run through the process early.

Let's try the five why's approach?  *Why* did you decide to run
through the process early, given the levels of unknowns?  What were
you concerned about that couldn't wait until 2023?

Enquiring minds want to know....

    	      	    	 	       	     - Ted

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jun 2019 23:55:38 +0100

Hiya,

Just on this bit...

On 26/06/2019 23:09, Carsten Bormann wrote:
> and do we want to address this and/or our expectations of the RSEâ€™s
> job and the RFC publication series as a whole.
I think it'd be great to know if the community really
do or do not want to consider these questions. (It's
very clear some people do want some changes. It's far
from clear to me at least that there's some form of
consensus for any one change.)

However, we probably oughtn't expect too much too soon.
Sarah will know better than I, but given the timeframe
in which we'll need a new RSE, I'd be shocked if the
community could properly process those questions in time
for that. In fact more than shocked, I just don't believe
it:-)

If you work back from Jan 1 2020 to the time when an RFP
will need to go out then I'm sure you'll quickly see that
we really don't have time for a proper community process
before this RFP iteration. (RSOC folks are figuring out
the details at the moment IIUC and they and/or Ted, as
IAB chair, will send mail soon about that.)

Put another way, given the timeframe, the next RSE will
be appointed according to current processes without any
substantive change to the role, and we still won't know
if the community do or do not want changes to the RSE
role whilst that process is running.

So, while your question above is a great one that I do
think we need to figure out how to finally clarify, it'll
take a while and any results won't have immediate effect.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Jun 2019 18:23:25 -0500

On Wed, Jun 26, 2019 at 03:45:59PM -0600, Sarah Banks wrote:
> [...]
> > 2) Because of this the RSOC decided we needed to recompete the RSE
> > and used the excuse of needing to tweek the RFP process - said
> > process that could have been delayed for almost 3 years but was
> > considered by the RSOC to be of critical importantance (why?) that
> > the RSE just did it now.
> 
> SB// I’m trying to understand why the RSOC is being belittled like
> this. Help me understand. We don’t need an excuse. The IAB doesn't
> need an excuse to reseat the RSOC - we serve at their pleasure. The
> contract doesn’t need “an excuse” to be extended, or not, for up to 2
> additional times after being awarded; there’s nothing in 6635 that
> states we need a reason. One would assume there’d be one; one might
> even hope there’d be one, and one should certainly expect a
> conversation about it. [...]

That seems to be the rub.  You didn't need a reason so you didn't think
you had to finesse the matter.  Now you have to find an RSE in a hurry
and you've upset a large part of the community.  Indeed, we're talking
about revamping the process significantly as a result of this incident.

Remember, that you *may* take some action X doesn't mean it's advisable
to do so.

Also, one does not take some business action X for no reason.  You might
want to keep your reasons private, understandably (e.g., your reasons
might hurt Heather's reputation and/or yours?), but that's so difficult
to do in an open organization answerable to its volunteer participants..
that it's difficult to understand why you'd even try.

Now, why would you tell a contractor that soon that you'll renew now but
not again later if not precisely because you want the contractor to not
re-up now?  Either RSOC lacks business acumen or RSOC thought no one
would notice that something went askew.  The latter case would be rather
surprising for such an open organization.

I don't think there's any way to avoid concluding that RSOC screwed up...

We could stop crying over spilled milk, but RSOC and IAB owning up to
their fault might help get the community there.

(It's also possible that the community shouldn't second guess RSOC, but
I think the community would not agree with that, clearly.)

Nico
--

---

From: Sarah Banks <[email-masked]>
Date: Wed, 26 Jun 2019 19:06:30 -0600

Nico,
   I wanted to address your top point before I step back from this a bit. While we don’t need a reason, per rfc6635, we specifically gave one. We could have done it in 2020, we could have waited for 2022, it’s true; it was a choice, reflected by the consensus of the RSOC. It was not my intention to say “we didn’t need one, so take that”, but rather, 1. Reflect what 6635 grants today and 2. Rearticulate what the RSOC had given as a recommendation. I understand that it’s rubbing some of the community the wrong way, and that weighs heavily on me, as I too personally share some of the concerns (and praise, and points for moving forward) raised. We can debate how or why, but let me be clear - the contract, how it was structured, was not a surprise to any parties involved. As Ted pointed out, it clearly states that we can choose to renew for 2 times before being required to put it out to bid. Heather has been through the entire process of the contract (initial award, reup, rebid) once, and was undergoing the second round. 

I agree that it’s desirable to understand what’s going on and why. I’ve done my very best to be as transparent as possible, sharing the consensus of the RSOC, and why we made the recommendation we made. I’m not sure how much more I can do on the list, but I make myself available here, privately at this address, or in person in Montreal, to discuss and share your concerns or feedback with. 

Yours,
Sarah

> On Jun 26, 2019, at 5:23 PM, Nico Williams <[email-masked]> wrote:
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 28 Jun 2019 09:07:33 -0700

Hi Adam,
At 12:29 PM 26-06-2019, Adam Roach wrote:
>By way of disclosure, I'll be the first to point out that I'm on 
>both the IESG and the RSOC, and so I'm going to have a certain 
>perspective on the events underway. I hope tha

I view the above disclosure as positive.

I'll disclose that I am currently serving on the ISEB in order to 
avoid any unclarity about conflict of interest.  I gather that my 
primary affiliation will not cause any issue as the information is not hidden.

Would it be possible to have some information about the impact of the 
YANG module processes on the relevant SLAs?

Regards,
S. Moonesamy

---

From: Michael StJohns <[email-masked]>
Date: Fri, 28 Jun 2019 14:24:10 -0400

Apologies for the delay on this - I didn't actually receive this 
directly and so this is cut and pasted from the archive.  This is a 
response to Sarah's original note.  My comments inline.

Michael,

Thanks
Sarah
 > 1) We the RSOC like Heather personally (or so the RSOC has said 
repeatedly).

SB// I don’t believe the RSOC has made a comment one way or another 
about “liking” Heather. The RSOC’s job isn’t to like someone - or 
dislike someone - it was to perform the IAB-delegated task of oversight. 
I think what you’re getting at is the part of my note that said that we 
wanted to bid the contract again, and that we were indicated that doing 
so was NOT a comment on Heather’s performance. That remains the case, as 
stated.

MSJ//  This was a reference to Adam's formation of the state of affairs 
and I agree that the RSOC hasn't indicated they like Heather.   However, 
why would you feel the need to make that comment if you didn't expect 
anyone to push back on the action? If you expected push back, why didn't 
you go talk to Heather and the community first about the grand plan to 
redo the RFP?

 > 2) Because of this the RSOC decided we needed to recompete the RSE 
and used the excuse of needing to tweek the RFP process - said process 
that could have been delayed for almost 3 years but was considered by 
the RSOC to be of critical importantance (why?) that the RSE just did it 
now.

SB// I’m trying to understand why the RSOC is being belittled like this. 
Help me understand. We don’t need an excuse. The IAB doesn't need an 
excuse to reseat the RSOC - we serve at their pleasure. The contract 
doesn’t need “an excuse” to be extended, or not, for up to 2 additional 
times after being awarded; there’s nothing in 6635 that states we need a 
reason. One would assume there’d be one; one might even hope there’d be 
one, and one should certainly expect a conversation about it. I’ve also 
answered the “why” portion of your question. The RSOC was concerned that 
the last time we went to bid, there was only 1 respondent. And while I 
am not trying to bring Heather into this, one of the things I deeply 
admired about her comportment was that she too brought this up as a 
point of concern. The RSOC, the IAB, indeed most of the IETF 
“leadership” (for lack of a better term) is comprised of volunteers. We 
have day jobs. Even in our day jobs when you get into executing big 
processes, the timeline can get away from you. Here, because there was a 
decent level of unknown raised by the new RSOC, we decided to run 
through the process early.

MSJ// I think Nico said it better than I can for the most part, but to 
reiterate a little bit: Simply because you *can* do something does not 
mean you *should* do it.  And with respect to the reseating of the RSOC 
- the stated goal (in the for the RSOC was continuity across NOMCOMs and 
IABs.  It seems the height of bad judgement to replace almost 100% of 
the RSOC in one go, especially without input from the RSE.

> In order to provide continuity over periods longer than the NomCom
>     appointment cycle [RFC3777  <https://tools.ietf.org/html/rfc3777>] and assure that oversight includes
>     suitable subject matter expertise, the IAB will establish a group
>     that implements oversight for the IAB, the RFC Series Oversight
>     Committee (RSOC).

SB// “Grudgingly” - where does that characterization come from? Help me 
understand. We didn’t enter this lightly. We were concerned that bidding 
the contract again would be construed as something other than where we 
landed; but no one said terminate.

MSJ//From this language in your note to the IAB:

> We recognize that with 2020 coming closer, the ability
>     to rebid in the short term would be too narrow. Our full
>     recommendation is to reup at the end of this year, and then go out
>     to bid in 2021 for the 2022 timeframe.

I read that as "we'd really rather terminate the contract this December, 
but we're out of time, so let's give the RSE the extension and rebid it 
as soon as possible.".  I think I'm fair in assigning the word 
"grudgingly" to this:

>
> adverb: *grudgingly*
>
> 1.
>     in a reluctant or resentful manner.
>     "I grudgingly accepted his apology"
>

SB// No where in my language, in the RSOC language, actually, of our 
discussions, was the word “terminate” used. I can’t speak for other’s 
intents and motivations, and consensus doesn’t always mean every one 
agreed, but the RSOC never recommended terminating the contract.

MSJ //  I hate that people don't know definitions and can't use them 
properly.  The definition of terminate is "bring to an end". Your/RSOC's 
action set a termination date for the contract (brought the contract to 
an end) at the 4 year point and is no less a termination than if you'd 
executed the 90 day termination clause.

SB// As was previously stated at some point on this very, very long 
thread, there is nothing that barred the current RSE from bidding for 
the job again. I’m human, all members of the RSOC are human, so I accept 
that we might have better worded our recommendation. If that’s your 
position, please, send me the language, and I’d be happy to review with 
the RSOC and note where we can improve.

SB// Just to be pedantic, we did not send a note to the IAB with 2 and 
3; we sent the note, which Ted has now shared as part of the IAB 
minutes, recommending to extend, and then rebid, to refine the process 
that some felt was not executed well the first time.

//MSJ:

"Heather - you're doing a fine job.  We've recommended to the IAB and 
the LLC that we exercise the upcoming renewal".  PERIOD.

 > 5) Heather, analyzing both what has been said and not said declined 
the extension for the reasons she stated.

SB// Heather has sent 2 notes to the list on her reasons. If there’s any 
confusion here, I suggest re-reading them.

MSJ// Ditto.

 > 6) Some of us are sad, and I'm not sure of who that includes.

SB// Speaking for myself, I am extremely disappointed and sad that she 
is leaving, particularly in this way. I am very sad she’s felt the way 
she has, and I sincerely hope that this doesn’t change the amount of 
positive and grateful feedback the community has sent in the middle of 
all of this, or cast a shadow on the actual work she’s delivered as RSE.

SB//We knew when we made the recommendation that this outcome was a 
potential risk.

MSJ// Then why didn't you mitigate your risks and the possibility of 
community approbation by bringing in Heather (to discuss how to 
implement remediation of her successor concerns) and the community into 
the discussion before making a recommendation? And isn't it true that 
your note to Heather couched this as a "decision" not a recommendation?

SB//Unfortunately, I don’t have the skills to rewind this clock and undo 
all of the pieces that got us here. But I’ll also state this, from my 
own personal perspective. The notion that the RSOC recommendation alone 
is what prompted Heather to not reup her contract is absurd. Evidence? 
Heather’s 2 notes make that clear. My own personal experience with 
Heather is that she has not shown herself to be impulsive; she’s also 
shown herself to take the longevity of the role of RSE seriously, both 
in her views of the RFC Series and longevity, as well as the RSE role 
herself. All of that leads me to say again - the notion that the RSOC 
made a recommendation to extend the contract 1 year and then rebid - 
this notion alone would be why Heather would not stay on as RSE doesn’t 
hold water.

MSJ// You are correct that it wasn't just the contract termination that 
prompted this, but the RSOC and IAB appear to be the prime movers in the 
other factors listed by Heather in her notes.

MSJ// And by now I think you know that the extension had to be for 2 
years, not just 1.

SB// Finally, I’ve seen some wonderful points and concerns and potential 
next steps come out of this. I sincerely hope that we as a community can 
continue to make progress in that lane. Examine what went “wrong” (could 
be refined, changed, made better, etc), decide where we want to go, and 
then take the transparent steps to get there.

</2 cents>
Sarah

MSJ//   While it might be impossible for the RSOC to turn back time, I'm 
wondering if there are any actions by the community that might allow for 
a restoration of the status quo ante with respect to the RSE, but not 
necessarily the IAB or RSOC.  I have a number of knee jerk reactions 
that fall in the category of changes - but they are probably suspect 
because they are knee jerk reactions so I'll hold off on them for now.

Thanks for your thoughts on the matter, but I'm still finding it 
difficult to reconcile what the RSOC did with your stated reasons for 
doing so.

Mike

> arah