[rfc-i] Developing consensus, episode 3.

Olaf Kolkman olaf at NLnetLabs.nl
Tue Feb 15 12:58:03 PST 2011


On Feb 11, 2011, at 6:36 PM, Dave CROCKER wrote:

> 
> Olaf,
> 
> Latest draft looks quite good.
> 
> A few comments and suggestions, with most being minor wording changes, but a few nuggets scattered throughout...
> 
> 
>> 2.1.  Executive Management of the Publication and Production function.
>> 
>>   o  The RSE provides input to the IASA budget, statements of work, and
>>      manages vendor selection processes....
> 
> While the sub-section title specifies the scope of the reference, I suggest that the first bullet's first sentence repeat it, for safety.  So, something like:
> 
>   o  With respect to the Publication and Production functions, the RSE
>      provides input to the IASA budget, statements of work, and
>      manages vendor selection processes.  The RSE performs annual
> 

ACK


> 
> -----
> 
> However, the phrase "manages vendor selection processes" appears to be in conflict with the next bullet:
> 
>>   o  Vendor selection is done in cooperation with the streams and under
>>      final authority of the IASA.
> 
> While the 'Concretely' bulleted list after this can be taken to clarify things, it would be better not to invite the confusion.
> 
> Perhaps the way to resolve this is to have the first one say
> 
>   and manages the vendor search processes
> 
> and have the latter say
> 
>   Final vendor selection is done...
> 
> This clarifies that the two roles of primacy are sequential and it invokes a common distinction between search/recommendation vs. selection. I believe this accurately reflects what is meant by the text and by the prior discussion.

ACK.

> 
> 
> -----
>>      *  with the RSE to provide advice and assistance as the IASA deems
>>         useful in those later stages
> 
> 
> Given the new wording of "The IASA will remain in close consultation with the RSE", this last bullet does not seem to be needed any more.  If retained, it should be cast as "The RSE will provide".
> 
> But "as the IASA deems useful" can actually be interpreted to conflict with the requirement for "close consultation" /requirement/ of the preceding bullet.  So I suggest just removing the latter.
> 
> 

Dropped that last bullet, it was a remnant of earlier edits.


> -----
> 
>> In case of
>>      disagreement the IAB acts as mediator.
> 
> Mediation does not assign authority for making a final decision to the IAB. It's a "facilitation" mechanism.  I'm a fan of mediation as a preferred mode of conflict resolution, but it's not enough for some circumstances.  While "arbitration" would be a formal term of art that resolves this ambiguity, I suggest something less legalistic:
> 
>   In case of disagreement, the IAB will attempt to mediate the issue.
>   If no mutual agreement can be reached, the IAB will make the final
>   decision.
> 

Seems like a clarification of the current ideas, so ACK again.


> -----
> 
>>   o  The RSE has operational responsibilities for issues that raise
>>      above the responsibilities of the publication or publication
>>      functions such as cross stream coordination of priorities and
>>      other issues.
> 
> Hmmm.  What happens if the RSE asserts authority for an ops issue that a Pubs contractor thinks is out of the RSE's scope?
> 

Than we work it out. Seriously, if we are in this situation than the RSE has a lot of de-facto power and the way we have written all this is that the RSE steers most of the ship. If the RSE starts to micromanage than we are in operational nightmare land and its up to the IAOC, they still have final authority.


If we have an RSE that elects to assert authority on the fact that pencils used by the publication contractor have to have those little erasers on their end, then certainly there are ways to make clear the person is micromanaging the lot and such does harm to the series.



> More broadly, this language does not explicitly declare that the RSE supervises on-going performance of the Pubs contracts.  I thought we had some earlier language that stated this directly and I recommend we use it.
> 

Yep, I think it would be good to make such explicit. I will put it in the the draft, expecting that both Glenn and Joel will turn it into more useful prose.


Currently that paragraph reads:

          The RSE primaraly supervises the on-going performance of the
	  vendors whitout asserting operational responsibilities.
	  However, the RSE has operational responsibilities for issues tha



> 
> -----
> 
>> The job is expected to take on average half of an FTE (approx 20 hrs
> 
> While I think that's the consensus, I'm wondering how it will be handled if the average turns out to be low?  This is more of a budget and contracting issue than a "policy" one.  The document might want to leave it to the IAOC to decide this, since there are standard ways to deal with the issue.

Agreed. As said this document captures consensus and is not yet the guidance to all.  Also if the job turns out to be much less than the expected amount of hours you want instruments to tune it. 

> 
> However the different ways have very different implications.  One approach is open time-and-materials, which ensures that the RSE can spend the necessary time, but has an open-ended budget impact.  Another is fixed-time, which means that some work won't get done.  Another is fixed-work which means the RSE is to take whatever time is needed to get the work done.  That's a bit unusual for anything less than full-time, I think.
> 
> Mumble.
> 

Mumble indeed :-)

Although I do not think that 'some work doesn't get done', it may just take a little longer. It could well be that the 'load' is being assessed at review time and contracts are slightly adjusted if there are for instance demonstrably high load and high priority projects.  

I believe that we are clear that if something like this would need to happen the RSOC would give such advice in the context of a budget proposal to the IAOC in combination with the review provided to the IAB.





[skipped a bunch of nits because perfect is the enemy of the good. At least for this very ephemeral document which I hope will evaporate as soon as 5620bis is done... :-) In other words I did not address all of them. ]

> 
> -----
> 
>>   large enough
>>   to provide general Internet Community expertise, specific IETF
>>   expertise, Publication expertise, and stream expertise.
> 
> There are important policy implications in the balance of representation of these different constituencies.  Too many from one means they dominate. I suggest some language be added to indicate a policy preference for the balance.
> 
> My own preference is an equal balance of stream producers and community consumers, with a smattering of publication expertise.

How about a modification that Glenn suggested that captures the actual purpose of getting a mix:

 Members serve at the pleasure of the IAB and are
 expected to bring a balance between short and long term
 perspective.

> -----
> 
>>   The RSE and a person designed to represent the IASA will serve as ex-
>>   officio members of the RSOC but either or both can be excluded from
>>   its discussions if necessary.
> 
>     designed -> designated
> 
> However if 'designed' is actually meant, then I suspect we are into the realm of genetic breakthrough...
> 
> 
> Broadly, the question of non-voting 'liaison' vs. voting 'member' is worth calling out.  I take the language, here about ex-officio as meaning the former.



Yes I thought of non-voting. However,  since the RSOC doesn't actually make decision it shouldn;t be voting. If (rough) consensus cannot be reached  for a recommendation for IAB decision than I believe the arguments why such decision cannot be made should be carefully presented to the IAB and the IAB should take the time to study those differences before making a decision.

--Olaf

Posting version 03 shortly.




________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20110215/4d46a711/attachment.p7s>


More information about the rfc-interest mailing list