Subject: New proposal/New SOW comment period

From: Sarah Banks <[email-masked]>
Date: Fri, 30 Aug 2019 09:38:44 -0700

(Cross-post with [email-masked])

Hello,
	The RSOC has received a lot of feedback regarding the current SOW, in addition to the feedback received generally around the RSE role, both on and off list, and at the microphone at the plenary session in Montreal. We've listened, discussed, and come up with a proposal that you'll find attached here.
	
	Broadly speaking, the RSE role contains 2  functions, a strategic function and a tactical function. We believe that we, as a community, still want RFCs published while we discuss the RSE role evolution. We also have a contract in place with the RPC (both Production Center and Publisher), both of whom are accustomed to a day to day contact to lean on for assistance (the current RSE). 
	
	With that in mind, we are proposing a temporary position that focuses on the tactical components of the current RSE role, with 2 large work items in mind. 

	First, this temporary position (called the Temporary RFC Series Project Manager) would serve as the day to day contact for the RPC, assisting with tactical items.

	Second, this role would focus on the v3 format work, assisting with the delivery of the new tools for the format work, and bringing the new format work to a close.

	Details are included within the SOW, attached with this email. 

	The IAB plans on sharing a follow up email shortly, that covers possible next steps for the strategic portions of the RSE role and the evolution discussion. 

	We'd like to open a 2 week comment period on the SOW, starting on August 30, 2019, closing ons on September 14, 2019. Please send your comments and feedback to the RSOC ([email-masked] <mailto:[email-masked]>).

Kind regards,
Sarah Banks
For the RSOC

---

From: Michael StJohns <[email-masked]>
Date: Fri, 30 Aug 2019 13:30:22 -0400

Five immediate large items:

0) The requirements for this position are pretty much indistinguishable 
from that of the RSE as stated in previous versions of the SOW.   I 
don't think that makes sense.  If this is simply a "we want to hire some 
short time to do the RSE position", then state that rather than using 
the figleaf of strategic and tactical.  I'm not saying you'll get 
community buy-in for that, but at least it would be less obfuscated.
1) Is this a full time position?  If not, then describe the expected 
workload.   From the description, its a level of effort contract 
somewhat less than full time. State that level.
2) The style manual (last bullet) is a strategic item, not a tactical 
item.  Delete it.
3)  Matrix management - seriously? That's how we got to this situation 
in the first place.
4) Term - for a tactical contract, this is pretty long - 1.5 years with 
the possibility of a year extension.

Small items:
1) Drop the "Experience as an RFC editor" bullet in favor of 
"Familiarity with the RFC series is desired but not required".
2) The "culture and process" bullet is also strategic and not 
tactical.   Drop this to just the RFC process.
3) Travel internationally - state if this is in addition to the IETF 
meetings.

Overall comment:

This has the feel to me of a push towards a more "managed" RFC Editor vs 
the independent model we've had over the lifetime of the series - and 
doing it by small nibbles and by delay.  The RFC++ bof indicated 
community displeasure with that direction, and I'm not sure this SOW is 
representative of community desires.    I'd be happier with this if the 
sole and only contract reporting link is from this contractor to the 
LLC.  The LLC MAY appoint the RSOC for day to day things, but any 
contractual discussions OF ANY KIND should be with the actual 
organization that holds the contract.   From a community point of view, 
we have oversight and a direct line of responsibility from the LLC to 
the community (with the concomitant ability of the community to recall 
or otherwise fail to reappoint LLC board members) .  That is not the 
case with the RSOC.

With respect to the evolution of the RFC Series - I haven't seen any 
clear statement from anyone of the changes they believe need to be 
made.  So, prior to putting us in the penalty box for a year and a half, 
perhaps we could actually get a statement of interests which would 
indicate that we need such a delay in the RFC SE selection process.    
E.g. a full formal ID/RFC not random musings in email with enough 
initial support that we have the possibility of getting to some sort of 
consensus for change if we invest the time.

Later, Mike

On 8/30/2019 12:38 PM, Sarah Banks wrote:
> (Cross-post with [email-masked] <mailto:[email-masked]>)
>
> Hello,
> The RSOC has received a lot of feedback regarding the current SOW, in 
> addition to the feedback received generally around the RSE role, both 
> on and off list, and at the microphone at the plenary session in 
> Montreal. We've listened, discussed, and come up with a proposal that 
> you'll find attached here.
> Broadly speaking, the RSE role contains 2  functions, a strategic 
> function and a tactical function. We believe that we, as a community, 
> still want RFCs published while we discuss the RSE role evolution. We 
> also have a contract in place with the RPC (both Production Center and 
> Publisher), both of whom are accustomed to a day to day contact to 
> lean on for assistance (the current RSE).
> With that in mind, we are proposing a temporary position that focuses 
> on the tactical components of the current RSE role, with 2 large work 
> items in mind.
>
> First, this temporary position (called the Temporary RFC Series 
> Project Manager) would serve as the day to day contact for the RPC, 
> assisting with tactical items.
>
> Second, this role would focus on the v3 format work, assisting with 
> the delivery of the new tools for the format work, and bringing the 
> new format work to a close.
>
> The IAB plans on sharing a follow up email shortly, that covers 
> possible next steps for the strategic portions of the RSE role and the 
> evolution discussion.
>
> We'd like to open a 2 week comment period on the SOW, starting on 
> August 30, 2019, closing ons on September 14, 2019. Please send your 
> comments and feedback to the RSOC ([email-masked] <mailto:[email-masked]>).
>
> Kind regards,
> Sarah Banks
> For the RSOC
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Aug 2019 19:00:18 +0100

Hiya,

Just on two of the more general points; (I'm sure Sarah or
someone else from RSOC will reply to the SOW specifics)...

On 30/08/2019 18:30, Michael StJohns wrote:
> doing it by small nibbles and by delay.

We had a joint IAB/RSOC call before these mails went out and
my estimation of that was there everyone who was on that call
really wanted the community to determine whether or not we
end up with a more "managed" RSE or a more independent one as
we have now. From what I've seen and heard, there are people
with varying opinions on that managed vs. independent continuum
both within and outside the IETF leadership. So, no, I don't
think it'd be fair to describe this as "a push towards" more
managed. (Given the history, I can understand if some people
have that impression though.)

> With respect to the evolution of the RFC Series - I haven't
> seen any clear statement from anyone of the changes they
> believe need to be made.

I don't believe we have a clear statement of changes that may
be desired. Partly, that's I guess because people have different
opinions as to where it's best to end up. But from chatting
with people, I do think there seems to be a fairly widespread
opinion that having the RSE be supposedly responsible for
day-to-day supervision of the RPC (as is called for in RFC6635)
isn't a good plan today. And that opinion seems to be held by
people from all parts of the managed vs. independent continuum
mentioned above. So while there isn't afaik anything like a
complete list of proposed changes, there do seem to be some
changes that may be uncontroversial and useful. (I'm fairly
sure there will also be some ideas in this space that will
be controversial:-)

Cheers,
S.

---

From: Sarah Banks <[email-masked]>
Date: Fri, 30 Aug 2019 12:39:50 -0700

Hi Mike,
	Some thoughts, inline. Speaking for myself. SB//

> On Aug 30, 2019, at 10:30 AM, Michael StJohns <[email-masked]> wrote:
> 
> 0) The requirements for this position are pretty much indistinguishable from that of the RSE as stated in previous versions of the SOW.   I don't think that makes sense.  If this is simply a "we want to hire some short time to do the RSE position", then state that rather than using the figleaf of strategic and tactical.  I'm not saying you'll get community buy-in for that, but at least it would be less obfuscated.

SB// The thought here was as intended; specifically on tactical, and nothing more. It IS focused on what the current RSE does tactically - I'm not sure how we change that until the community has a conversation about the role. I'm all ears and open to suggestions, though!

> 1) Is this a full time position?  If not, then describe the expected workload.   From the description, its a level of effort contract somewhat less than full time.  State that level.

SB// The RSOC in years past has specifically stayed out of the "how long does it take to do the job" and the "this is a 32-hour-a-week" job. I'd defer this to the LLC; if the person they're hiring is a contractor I'm not sure this matters, since they're bidding on the total amount of work (that's been the thought) versus the employee who clearly needs to understand if this is a part time or full time job. 

> 2) The style manual (last bullet) is a strategic item, not a tactical item.  Delete it.

SB// I could live with this, thanks.

> 3)  Matrix management - seriously?   That's how we got to this situation in the first place.  

SB// We understand that's a concern, and it should probably be one of the items we discuss as a community. We're not looking to force the process though, and to that end, using the process we have (this language came from the previous SOW we used, in fact) seemed prudent. Given that they're focused on the RPC and the new format work and reporting to the RSOC, how else would you propose we address your concern?

> 4) Term - for a tactical contract, this is pretty long - 1.5 years with the possibility of a year extension.

SB// As I previously explained, we as a community don't tend to have short conversations. The process will take time. If we conclude in less than 1.5 years then fantastic, we'll have some overlap with whatever outcome we get from that discussion and the current/temporary RFC Series Project Manager. That seems like an acceptable thing to me.

> 
> Small items:
> 1) Drop the "Experience as an RFC editor" bullet in favor of "Familiarity with the RFC series is desired but not required".
> 2) The "culture and process" bullet is also strategic and not tactical.   Drop this to just the RFC process.
> 3) Travel internationally - state if this is in addition to the IETF meetings.
> 

SB// These seem reasonable.

> Overall comment:
> 
> This has the feel to me of a push towards a more "managed" RFC Editor vs the independent model we've had over the lifetime of the series - and doing it by small nibbles and by delay.  The RFC++ bof indicated community displeasure with that direction, and I'm not sure this SOW is representative of community desires.    I'd be happier with this if the sole and only contract reporting link is from this contractor to the LLC.  The LLC MAY appoint the RSOC for day to day things, but any contractual discussions OF ANY KIND should be with the actual organization that holds the contract.   From a community point of view, we have oversight and a direct line of responsibility from the LLC to the community (with the concomitant ability of the community to recall or otherwise fail to reappoint LLC board members) .  That is not the case with the RSOC.
> 
> With respect to the evolution of the RFC Series - I haven't seen any clear statement from anyone of the changes they believe need to be made.  So, prior to putting us in the penalty box for a year and a half, perhaps we could actually get a statement of interests which would indicate that we need such a delay in the RFC SE selection process.    E.g. a full formal ID/RFC not random musings in email with enough initial support that we have the possibility of getting to some sort of consensus for change if we invest the time.
> 

SB// The goal is to have the conversation as a group, and figure out what to do. if we don't want a managed RFC Editor, but the independent model that folks believe we should have, then as a community we should say that, and figure out how to instrument what we want. Personally, I like the spirit of what was described to me starting with Postel, and having some independence from being told what to do blindly with the ability to push back doesn't seem to be a bad thing. But that's my personal thought, and as an RSOC it's not our current purview to tell the community what to do. We're trying to strike a balance between the process we have, which keeps our contractors moving and documents flowing, and allowing the community to do its thing. This position "reporting" to the LLC makes little sense to me - 1. that's not the current process we have (and if you don't like it, speak up and change it, Ted's outlined how we might proceed to doing that) and 2. The LLC really isn't equipped to handle it either. The RSOC seems to be the reasonable choice given the situation we find ourselves in, and again, this is a 1.5 year contract with clearly described goals. We'll have the conversation to change (or not) - in the grand scheme of things, this doesn't seem to be an issue to me. The alternatives concern me more - do we just not have an RSE-like function at all, in any capacity, being executed, while we chat as a group? No documents are published? We're paying for the RPC function by contract now; I'd like to see our money well spent, personally. I'm not sure I understand the analogy to a penalty box, but if you mean we're in a holding pattern until we figure out what we want then yes, I totally agree, we are, and I don't see a better alternative. I'm happy to discuss any alternatives you might have.

/S

---

From: "Matthew A. Miller" <[email-masked]>
Date: Fri, 30 Aug 2019 17:09:17 -0600

Please note that discussion on the Temporary RFC Series Project Manager
SOW should occur at < [email-masked] >.  As per RFC 3005,
the general list is appropriate unless there is a more specific venue.

Information about the list, including how to subscribe, can be found at
< https://www.rfc-editor.org/mailman/listinfo/rfc-interest >.

Thank you,

- Matthew A. Miller
Sergeant-at-Arms

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Aug 2019 10:20:54 +0200

Can the Sergeant-at-Arms please not be this trigger happy?

This was the focus of the discussion at the administrative plenary, and deserves wide attention, in part because the matter is urgent to close, given the limited period of time, and quite frankly what Sarah is asking for amounts to last call comments.  The IETF list has always welcomed those.  Do we really need to reopen 3005 to make that point clearer?

Eliot

> On 31 Aug 2019, at 01:09, Matthew A. Miller <[email-masked]> wrote:
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 31 Aug 2019 11:32:42 +0100

Hi Sarah,

[Deliberately continuing the discussion cross-posted despite the Sergeant At Arms’ entreaties]

Thanks for coordinating the construction of this draft and for putting it out for comment.

In the ensuing discussions…

>> workload.   From the description, it's a level of effort contract
> SB// The RSOC in years past has specifically stayed out of the "how
> long does it take to do the job" and the "this is a 32-hour-a-week"
> job. I'd defer this to the LLC; if the person they're hiring is a contractor
> I'm not sure this matters, since they're bidding on the total amount of
> work (that's been the thought) versus the employee who clearly needs
> to understand if this is a part time or full time job. 

When people bid fixed-pay fixed-deliverables on a contract, they usually have a pretty detailed description of the work, that way they can work out how much time they think it will take them, and bid accordingly. If such detail is not available, a wise contractor will make an estimate and add a lot of contingency. That puts up the price paid by the customer, potentially unnecessarily. OTOH, an unwise or "keen" contractor may under-bid risking that a poor job will be delivered. Frankly, the more detail supplied, the more accurate the bid and the better the work.

Alternatively, the customer may give better guidance as to the expected amount of work. The draft says that RFC 6635 section 2.15 is not applicable, and (of course) that is true because this SoW does not cover all of the job described in the RFC. But at the same time, it should be clear to everyone that if 6635 considered that the job was 20 hours per week and nearly full time during IETF week, then the work covered by this SoW is bounded by that as an upper limit.

Anyway, I don't think the current draft has enough detail of what the job is to enable a meaningful bid. Maybe this is fixed by simply adding something to say that during the process of preparing bids and on request, the RSOC will make available to bidders additional information to help them scope and understand the nature of the tasks.

Further to the tactical/strategic discussions on the list, I don't think it is helpful to show your thought processes in the SoW. I would suggest:
- Strike "The RSE’s job functions can be logically split into 2 functional areas: strategic and tactical." 
- Replace "is being created to fill the tactical functions of the RSE role" with "is being created to fill certain functions of the RSE role as listed below"
- Strike "These “tactical” responsibilities of the RSE are not defined explicitly in RFC6635; the expected nature of the work is explained below."
Doing this would allow you to make the list of tasks you want done, without getting into discussion of whether they are 73% tactical and 27% strategic.

I struggle with the following paragraph:
   Some of the functions described below may not be possible within that timeframe
  (for example, chairing the search committee when the RPC contract goes out to bid
  again). It is expected that this position and the person filling it will work with the
  RSOC to identify new or changing work items as they arise.

To me this reads as though you want the contractor to be very flexible on deliverables. Firstly you are giving permission for the contractor to not deliver some things: I guess that's OK, no one will object to being paid for not delivering 😊 Second, you might be saying that new/changed deliverables may arise, but you are not making it clear whether you expect them to be delivered under the contract or not. The usual way to handle both of these points is "variations by mutual agreement in writing."

Why "Scope of work - primary"? Is there a secondary scope of work somewhere?

I would expect to see a termination clause.

The line "This relationship is subject to later reorganization" should be business as usual in a contract like this, but the history suggests that it might be better to be a bit clearer. Just as a point of note, the previous paragraph names the RSOC as the body with whom scope changes might be identified, but (presumably) if the reporting changed, that wouldn't be true.

Finally (you'll be glad to hear), what is the purpose of item 3 on the Affidavit? Is the intention here that you propose that only entities registered in the US for tax purposes may win this contract?

Good luck!
Adrian

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Aug 2019 08:54:55 -0400

(changing the subject line to try to avoid a nasty S/N problem)

--On Saturday, August 31, 2019 10:20 +0200 Eliot Lear
<[email-masked]> wrote:

> This was the focus of the discussion at the administrative
> plenary, and deserves wide attention, in part because the
> matter is urgent to close, given the limited period of time,
> and quite frankly what Sarah is asking for amounts to last
> call comments.  The IETF list has always welcomed those.  Do
> we really need to reopen 3005 to make that point clearer?

Matthew,

I wouldn't have chosen "trigger happy" as a description, but I
agree with Eliot and would go a bit further.  First, as he
points out, this topic was of broad enough concern in Montreal,
and drew enough list discussion in the prior weeks, to have
dominated the administrative plenary. It is clearly of broad
concern to the community and I appreciate Eliot's comparison to
a Last Call.  

There is, however, another issue: the rfc-interest list has
traditionally focused on substantive issues with RFCs and the
RFC Series, not personnel and administrative policies.  Pushing
this discussion there is inconsistent with "Discussions that
fall within the area of any working group or well established
list" because this is not clearly within the area of that list.
More important RFC 3005 clearly calls out "Discussion of IETF
administrative policies" as an appropriate posting topic and
this discussion is very much about administrative policies.

So, please reconsider your comment and back it out.  Where I
disagree with Eliot is that, if you don't consider withdrawing
your instruction appropriate, I think the appropriate action, at
least in the short term, would not be to open 3005 but to appeal
your decision.

thanks,

   john

---

From: Bob Hinden <[email-masked]>
Date: Sat, 31 Aug 2019 08:18:00 -0700

Hi,

> On Aug 31, 2019, at 5:54 AM, John C Klensin <[email-masked]> wrote:
> 

I agree with Elliot, S. Moonesamy, and John.   The Sergeant-at-Arms email was ill considered and should be withdrawn.

Bob

---

From: Keith Moore <[email-masked]>
Date: Sat, 31 Aug 2019 14:15:59 -0400

I agree with others who have asked the SAA to retract his recommendation 
to move the discussion.

It's not easy to think of a topic more important to the future of IETF 
than the manner in which its output is published.   To suggest that this 
topic should not be discussed in IETF, but should instead be discussed 
in a venue outside of IETF, defies all logic.

It also prejudices the outcome.   One of the ways that US politicians 
manipulate elections, is by making it more difficult for people that 
they think will not vote in their favor, to vote.   For instance, they 
may reduce the number of polling places in areas that are known to be 
sympathetic to the other side. Forbidding discussion of management of 
the RFC series on the IETF list and insisting that it be discussed 
elsewhere, reminds me of this.   It basically says "if you want to 
discuss this topic, you need to jump through additional hoops", with the 
awareness that few people will do so.   I understand the need for 
someone to keep discussion civil, but I don't think it's appropriate for 
that person to prejudice the outcome of discussions - especially 
discussions that are vital to the organization's future.

More broadly, the IETF is a group of volunteers, and it's essential for 
an organization that relies on the creative contributions of volunteers 
to have trust in its leadership. The open plenary at face-to-face 
meetings is one of the mechanisms that has helped promote such trust, 
and the IETF list has traditionally served a similar function for online 
discussion and between meetings.   Trying to move a controversial 
discussion off of the IETF list has the effect of undermining the trust 
that several successions of leaders have spent decades cultivating. 
That's not to say that the IETF list could not be forked - but not 
without discussion, and not over a single topic of broad importance.

Keith

---

From: Adam Roach <[email-masked]>
Date: Sat, 31 Aug 2019 14:02:05 -0500

On 8/31/19 1:15 PM, Keith Moore wrote:
> than the manner in which its output is published.   To suggest that 
> this topic should not be discussed in IETF, but should instead be 
> discussed in a venue outside of IETF, defies all logic. 

I think this overstates things a bit.

One of the key objections that was repeatedly raised regarding the 
RFCPLUSPLUS BOF was that it took place within the context of IETF 
process, and since it had implications on streams other than the IESG 
stream, ran the risk of overstepping its bounds [1]. I believe it's 
pretty clear, even ignoring RFC 3005's "well-established list" clause, 
that whatever sincere concerns existed about proposing changes to the 
RFC Editor function solely within the IETF process back then must 
necessarily translate to holding a more existential discussion about the 
future of that function on an IETF mailing list list.

To be clear, I suggested to the SAA that the conversation had this very 
risk of overstepping the bounds of the IETF's purview, as was clearly 
communicated by the community during that BOF. Any criticism of this 
logic should be directed at me rather than him.

/a

____
[1] There were many such comments, both on-list and at the microphone. 
This one is representative: 
https://mailarchive.ietf.org/arch/msg/rfcplusplus/jQHmeaGqN231LNIPfCQwpeUIxds

---

From: Keith Moore <[email-masked]>
Date: Sat, 31 Aug 2019 15:10:53 -0400

On 8/31/19 3:02 PM, Adam Roach wrote:

>> It's not easy to think of a topic more important to the future of 
>> IETF than the manner in which its output is published.   To suggest 
>> that this topic should not be discussed in IETF, but should instead 
>> be discussed in a venue outside of IETF, defies all logic. 
>
>
> stream, ran the risk of overstepping its bounds [1].

I understand that such objections were raised, but do not presume that 
they were correct.   Suffice it to say that the topic is controversial.

The more distance that exists between IETF and the RSE, the greater the 
potential for the RSE to work at cross-purposes with IETF.   I 
understand both pros and cons with having a separation between the IETF 
and the RFC series.   But it's not wrong for the IETF community to want 
to have a say in how its output is handled, and it's certainly not wrong 
for the IETF community to want to discuss it.

Keith

---

From: Adam Roach <[email-masked]>
Date: Sat, 31 Aug 2019 14:22:30 -0500

> this discussion is very much about administrative policies.

By that logic, IANAPLAN, MTGVENUE, and IASA2 discussion should have 
taken place here, and redirecting them to their respective working group 
mailing lists would have been misguided. Would you have raised the same 
objection?

/a

---

From: Bob Hinden <[email-masked]>
Date: Sat, 31 Aug 2019 12:36:50 -0700

Adam,

> On Aug 31, 2019, at 12:02 PM, Adam Roach <[email-masked]> wrote:
> 
>> It's not easy to think of a topic more important to the future of IETF than the manner in which its output is published.   To suggest that this topic should not be discussed in IETF, but should instead be discussed in a venue outside of IETF, defies all logic.
> 
> 
> One of the key objections that was repeatedly raised regarding the RFCPLUSPLUS BOF was that it took place within the context of IETF process, and since it had implications on streams other than the IESG stream, ran the risk of overstepping its bounds [1]. I believe it's pretty clear, even ignoring RFC 3005's "well-established list" clause, that whatever sincere concerns existed about proposing changes to the RFC Editor function solely within the IETF process back then must necessarily translate to holding a more existential discussion about the future of that function on an IETF mailing list list.
> 
> To be clear, I suggested to the SAA that the conversation had this very risk of overstepping the bounds of the IETF's purview, as was clearly communicated by the community during that BOF. Any criticism of this logic should be directed at me rather than him.

Rereading RFC3005, it says:

   The IETF Chair, the IETF Executive Director, or a sergeant-at-arms
   appointed by the Chair is empowered to restrict posting by a person,
   or of a thread, when the content is inappropriate and represents a
   pattern of abuse.

The intended role of the sergeant-at-arms is for content that is is inappropriate and represents a
pattern of abuse.   There was no “inappropriate” nor “pattern of abuse” here whatsoever.

Bob

> 
> /a
> 
> ____
> [1] There were many such comments, both on-list and at the microphone. This one is representative: https://mailarchive.ietf.org/arch/msg/rfcplusplus/jQHmeaGqN231LNIPfCQwpeUIxds
>

---

From: Adam Roach <[email-masked]>
Date: Sat, 31 Aug 2019 14:55:20 -0500

This is a fair point. Is it your position that there is no supervision function intended to keep the discussion within the mailing list’s charter, aside from that required to tamp down abusive behavior?

/a

> On Aug 31, 2019, at 14:36, Bob Hinden <[email-masked]> wrote:
> 
> Adam,
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 31 Aug 2019 17:42:58 -0400

*sigh*

Adam - Hyperbole at this point is not helpful.  Specifically "no 
supervision" does not come even close to what we've been asking.... no - 
make that telling ...  the SAA to do.   Let's not distract the  
conversation off the topic.

The SAA MUST NOT be used as a tool, or even be perceived as being used 
as a tool to stymie dissent, or to stop or steer discussions that might 
be uncomfortable to the SAA or I*.   The fact that there is an RFC-I 
mailing list does not in itself mean that all RFC related discussions 
must take place on that list.

Matthew was wrong to attempt to get the discussion moved over and needs 
to use a much finer filter in the future, as do all of the SAA, on any 
discussion that might be a community pushback or even discussion on I* 
leadership proposals.

For now - let's keep it here.  If we get to a point where we're cycling 
on a few topics, and those topics are more appropriate for the other 
list (e.g. maybe more details on things that have a broad community 
buy-in), then yeah, feel free to suggest it.

By the way - while I'm on the topic:

The SAA should not participate in a conversation that it expects to have 
oversight on.  Listening is fine, advocacy for one side or another is 
pretty much disqualifying in acting as the SAA for that topic as SAA 
decisions could be seen to be tainted by bias.

  Later, Mike

---

From: Keith Moore <[email-masked]>
Date: Sat, 31 Aug 2019 18:43:32 -0400

> On Aug 31, 2019, at 3:55 PM, Adam Roach <[email-masked]> wrote:
> 
> Is it your position that there is no supervision function intended to keep the discussion within the mailing list’s charter, aside from that required to tamp down abusive behavior?

I don’t think this is an appropriate role for the SAA to assume.    Being off-topic is not anywhere nearly the same as abuse and should not be treated in the same way.  The very nature of the SAA role requires that it be used sparingly.   And I doubt that prior restraint by the SAA, of any kind of contribution to the IETF list, is ever appropriate.  

Keith

---

From: Adam Roach <[email-masked]>
Date: Sat, 31 Aug 2019 20:06:44 -0500

On 8/31/19 4:42 PM, Michael StJohns wrote:
> supervision" does not come even close to what we've been asking...

I'm sorry if that came across as hyperbole. I'm honestly trying to probe 
at what the community thinks RFC 3005 provides for. If there's some 
legitimate authority granted (by what language?) to someone (whom?) to 
provide such shepherding, I'm curious about what people think that looks 
like. The language that Bob cites, on its face, implies that it does not 
exist. I was simply trying to clarify that such was the point he was making.

The rest of your points are reasonable, and as long as no one else is 
objecting to the possibility of having this conversation on IETF 
territory [1] -- rather than a venue hosted by the RFC Editor -- then 
I'm happy to drop attempts to redirect the conversation. We've heard 
jurisdictional complaints in the past, and I'm simply trying to avoid 
them this time around.

I have one question for you:

> The SAA should not participate in a conversation that it expects to 
> have oversight on.  Listening is fine, advocacy for one side or 
> another is pretty much disqualifying in acting as the SAA for that 
> topic as SAA decisions could be seen to be tainted by bias. 

I understand the principle you're laying out. Your phrasing implies that 
you've seen instances of this happening, which I would find out of 
character for either Matthew or Benjamin. Have you seen this happening? 
Or are you just trying to ward off future issues?

/a

____
[1] Its impacts on the IRTF and ISE notwithstanding