Subject: [rfc-i] New proposal/New SOW comment period

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

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

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

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

Hi,
	Apologies for the missing attachment; PDF enclosed this time.

Thanks
Sarah

> On Aug 30, 2019, at 9:30 AM, Sarah Banks <[email-masked]> wrote:
> 
> Hello,
>

---

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

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

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

> Later, Mike
> 
> 
> 
> On 8/30/2019 12:38 PM, Sarah Banks wrote:
>> (Cross-post with [email-masked] <mailto:[email-masked]>)
>> 
>> Hello,

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 Aug 2019 12:58:26 -0700

Hello,
At 09:30 AM 30-08-2019, Sarah Banks wrote:
>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.

The difference between this statement of work and the one which was 
circulated a few months ago is the removal of the policy development 
areas from the role and the change from RSE to temporary project manager.

Who is going to plan and see to the execution of improvements in the 
RFC review and publication process?

Regards,
S. Moonesamy

---

From: Adam Roach <[email-masked]>
Date: Fri, 30 Aug 2019 15:15:42 -0500

On 8/30/19 2:58 PM, S Moonesamy wrote:
>> 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.
>

The IAB sent a follow-up note addressing this point.

/a

---

From: Jim Schaad <[email-masked]>
Date: Fri, 30 Aug 2019 18:53:47 -0700

I am having a problem trying to figure out what you mean when you say
tactical vs strategic in your mail.   There are a number of items which I
think of as strategic that you are placed in this SOW.  I would consider any
left over issues, and I expect there to be many, issues around the move to
the v3 xml2rfc vocabulary to be strategic.  Anything which deals with what
the long term format and display of RFCs is not something that is a short
term, let's get things done, type of problem to be solved, but is something
that needs to be examined as a long term issue.

It is not clear from the SOW if you believe that the Temp Series Manager is
supposed to be providing input into both the long term strategic re-write of
the RFC Editor model and to help in doing preparation of bid documents and
selection.  Given that this person is going to be the only one round with a
solid knowledge of how things work that would seem to me to be implied.
Again however, this is a strategic function.  

I have absolutely no idea of what is meant by the requirement "Familiarity
with a wide range of Internet technologies."  Does this mean that if I use a
web browser, an email client as well as an IM client and do web conferencing
that I meet this requirement?  I am using and thus am familiar with some of
the major technologies on the internet today.  Or instead to you mean that
there should be some type of familiarity with the workings of the technology
instead?  At least a part of me is just unsure how useful this requirement
is, after all the stream managers are the ones who are supposed to be
approving the technical content.  At most the RFC Editor needs is the
ability to say - but can the tools team, the RFC Publisher or a contractor
do something like the following to make the user experience better when
looking at the RFC Editor website.   If you mean the first then "Familiarity
with using a wide range of internet technologies." seems to be much clearer.

Jim

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 Aug 2019 22:34:05 -0700

Hi Adam,
>The IAB sent a follow-up note addressing this point.

Thanks for the pointer.

I am a bit skeptical when I see words such as "tactical" and 
"strategic" in organizational plans.  I would list that the execution 
of a plan under "tactical".

As a minor point, there has been several comments [1] about seeking 
someone with "RFC author" experience.  I don't understand the 
rationale for insisting on having that in.

Regards,
S. Moonesamy

1. One of the comments was from an IAB member.

---

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…

>> 1) Is this a full time position?  If not, then describe the expected 
>> workload.   From the description, it's 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. 

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: "Salz, Rich" <[email-masked]>
Date: Sat, 31 Aug 2019 14:50:54 +0000

>    I am a bit skeptical when I see words such as "tactical" and 
    "strategic" in organizational plans. 

I tend to agree.  Does short-term and longer-term make more sense?

---

From: S Moonesamy <[email-masked]>
Date: Sat, 31 Aug 2019 08:28:10 -0700

Hi Rich,
>I tend to agree.  Does short-term and longer-term make more sense?

The duration of the contract is described under "contract 
period".  It is also stated that this is a temporary position.  A 
person would likely read as that as not for a longer term, i.e short term.

Regards,
S. Moonesamy

---

From: Christian Huitema <[email-masked]>
Date: Sat, 31 Aug 2019 09:06:50 -0700

> On Aug 31, 2019, at 8:28 AM, S Moonesamy <[email-masked]> wrote:
> 
> Hi Rich,
> The duration of the contract is described under "contract period".  It is also stated that this is a temporary position.  A person would likely read as that as not for a longer term, i.e short term.

The intent behind the tactical word or  the proposed short term replacement is to qualify the impact of the work, not its timing. The contractor will drive matters that have short term effect, but will not be making decisions about the long term evolution of the RFC series.

-- Christian Huitema

---

From: Jim Schaad <[email-masked]>
Date: Sat, 31 Aug 2019 10:43:50 -0700

So the piece of mail from Russ makes for an interesting starting point for
discussion of what you believe this new person should be doing.

He has asked for a new feature, change bars, to be added to the v3
vocabulary and provided an example of when this has been done in the past.
This means that the person in charge needs to look at this feature request
and decide what to do with it.  Except for a decision to punt, this is a
decision that has long term effects on the RFC series.  Should this be
allowed?  If allowed how is it presented for the different document formats?
What is the mechanism that this is done in the vocabulary?  Does this mean
that we should have the full set of change bar features or not?  The current
document just has bars down the side, but does not have any insert or delete
markers.

Is this the type of decision that this new Temp RFC Series Manager supposed
to be making?  

Jim