[rfc-i] RSE relationship to the IAOC

Glenn Kowack Glenn at riveronce.com
Tue Jan 18 20:46:35 PST 2011


On Jan 18, 2011, at 7:23 PM, Bob Hinden wrote:

> Glenn,
> 
> Out of order:
> 
>> The above satisfies the need for technical-editorial expertise in revising (and 
>> creating new) agreements while not interfering with the IAOC's execution of its
>> responsibilities.  The above is also consistent with BCP 101, which identifies:
>> 
>> 	"The IASA is distinct from IETF-related technical functions, such as
>> 	the RFC Editor, the IANA, and the IETF standards process itself.  The
>> 	IASA has no influence on the technical decisions of the IETF or on
>> 	the technical contents of IETF work.  Note, however, that this in no
>> 	way prevents people who form part of the IASA from participating as
>> 	individuals in IETF technical activities."
>> 
>> This email defines RSE (and REOC) expertise as technical, and thus appropriate 
>> as described above.
> 
> If I understand correctly, you are saying that because you define this work as technical then this doesn't conflict with BCP101.  While this is a creative legalistic argument, I think it is wrong.  Most of you things say that the RSE would do here are not technical, they are contractual.  For example, writing and revising Statements of Work (SOW), leading the discussion on a SOW, and evaluating the sufficiency of bids w/r/t the SOW are not technical as intended in BCP101, they are contractual.  The activities you list are the responsibility of the IAOC.

The BCP 101 paragraph above explicitly calls the RFC Editor an "IETF-related technical function".  I was pointing at that.  And, as I also described, there are many, many aspects of RFC Editor and RSE work that depend upon expertise in editorial and publications techniques.  Based on that, my recommendations aim to apply that expertise where it is necessary, and defining SOW content is one of those. Of course it becomes part of the contract those items become contractual, but it still follows from significant understanding of and insights into the content of the work that the RSE will uniquely hold.

> By your logic, the IAOC could not be awarding any contracts for tools development because they have technical content.   Or to even hire a secretariat because it might require knowledge of how Internet Drafts are published.  This doesn't make sense.

I do not make this argument.  Like any other organization with responsibility for letting contracts, the IAOC should acquire outside (from elsewhere within the community) expertise for things where it is not expert.  That way they combine their expertise in contracts with specific subject-matter expertise. That's all I recommend here.

> I also don't think shared responsibility between the RSE and the IAOC will work well.  It needs to be in one place so that there is a clear owner.

This is the way I've designed my recommendations, below.  The RSE provides input to the IAOC in
the form of the SOW.

> Something similar to what you propose was done when hiring the TRSE.  That is the hiring committee did not look at costs and then the IAOC was told to negotiate a contract.  I won't go into details here, but it created a big mess.

I believe you may, at least in part, be making my case: the IAOC needs to be sure that the full 360 degrees of requirements are known and integrated when moving towards and completing contracts.

> The current approach of having the IAOC be the responsible party resulted in the awarding of the current product center and publisher contracts.  This worked well.  I didn't read anything in your motivation document that said otherwise.

This is correct.  I have not recommended anything that takes the IAOC out of this role.  That would be counterproductive: they have expertise in administration, contracts, legal, and financial matters that need to be applied for successful contract development and execution.

> I haven't seen any justification for a different process, especially one that would require changes in BCP101.  If BCP101 needs revision, then we should talk about that directly.

I have recommended an approach that does not require changes to BCP 101, so I think we may be
fairly close.

> What I think will work is that the IAOC creates a subcommittee for these RFPs that includes people with the expertise needed and stake holders. Not just IAOC members.  The subcommittee would write the RFP (based on what is in RFC5620 or bis), review and interview bidders, and make a recommendation to the IAOC.  The IAOC then makes a decision.  The change I would make is to add the RSE to this subcommittee.  This would insure that the RSE was directly involved in the process and his/her concerns taken into account.  In your words, to being in the technical expertise.  The decision would be made by the IAOC and confirmed by the IAB.

It's beyond the scope of my recommendations how the IAOC does the above work as long as the input of the RSE is appropriately integrated. Your text above could be entirely compatible with my recommendations (in the email below) if the RSE takes the lead on developing the SOW.  So we may once again be on the close to or on the same page.

thanks,
Glenn
___

> Bob
> 
> 
> On Jan 17, 2011, at 11:59 PM, Glenn Kowack wrote:
> 
>> Recent discussion on this list, as well as my own phone discussions, point toward
>> the following changes (since publication of the Overview in December) in RSE
>> responsibilities as they relate to the IAOC.
>> 
>> Two background items:
>> - The REOC may be constituted under the IAB's authority as defined in RFC 2850, 
>> 	Section 2(d): ("The IAB must approve the appointment of an organization to 
>> 	act as RFC Editor and the general policy followed by the RFC Editor.")
>> - The TRSE recommendations identify that the RSE requires technical (as in 
>> 	editorial and publications techniques) and managerial expertise.
>> 
>> It will occasionally, be necessary to revise existing (or create new) agreements for 
>> contracted RFC Editor services (e.g,. the Production Center).  New contracts and 
>> renewals use Statements of Work (SOWs) to describe all issues related to 
>> contractor work performance. The RSE will lead community discussion on the 
>> content of SOWs.  Using that input, the RSE will revise the SOW. The RSE will
>> then support the IAOC in developing an RFP, with the RSE providing input related
>> to technical-editorial SOW content.
>> 
>> All RSE activities will be done with the advice and consent of the REOC, whose 
>> members are expected to maintain their own independent contact with the 
>> community (per the Overview).
>> 
>> The RSE will evaluate the sufficiency of bids w/r/t the SOW, and will provide input
>> to the IAOC. The IAOC will negotiate contract(s) with the winning bidder, with the 
>> support of the RSE.
>> 
>> If during this process the RSE does not believe his recommendations and input 
>> are being considered appropriately by the IAOC, then he can bring that concern
>> to the IAB.
>> 
>> The above satisfies the need for technical-editorial expertise in revising (and 
>> creating new) agreements while not interfering with the IAOC's execution of its
>> responsibilities.  The above is also consistent with BCP 101, which identifies:
>> 
>> 	"The IASA is distinct from IETF-related technical functions, such as
>> 	the RFC Editor, the IANA, and the IETF standards process itself.  The
>> 	IASA has no influence on the technical decisions of the IETF or on
>> 	the technical contents of IETF work.  Note, however, that this in no
>> 	way prevents people who form part of the IASA from participating as
>> 	individuals in IETF technical activities."
>> 
>> This email defines RSE (and REOC) expertise as technical, and thus appropriate 
>> as described above.
>> 
>> -Glenn
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 



More information about the rfc-interest mailing list