[rfc-i] a possible refinement to draft-iab-rfc-editor-model

Leslie Daigle leslie at thinkingcat.com
Sun Mar 22 16:02:39 PDT 2009


Hi Brian,

I agree with much of your analysis, and certainly share some of the 
concerns.  Where I would like to take a different direction is in the 
conclusions:


Brian E Carpenter wrote:
  What bothers me a bit about this at first sight is that it potentially
 > creates shifting sands among the requirements, and that is a poor
 > basis for stable contractual operations.

I'm not really sure I get this "shifting sands" part.  Or, maybe I'm not 
being clear about the type of moderated changes I'm addressing.

 >  I'm a bit worried about
 > that. Your proposed committee would have to be chartered quite
 > narrowly to avoid that problem. I'm not sure how it's going to work,
 > since once an N-year contract is signed, the only tuning that can be
 > done is within the terms of the contracts, which are managed by the IAD.

There are important issues to evaluate during the course of an existing 
contract.   As you note, the Secretariat operates on an approximation of 
IETF consensus as judged by the IESG.  That doesn't stop the need for 
decisions about whether contractor-proposed changes are in-line with 
IETF expectations or not.  It does not prevent changes and upgrades even 
during the span of a contract.    The IAD signs off on any adjustments 
that impact contracts, and works with the contractors on specific 
implementations, but that's based on interpretation through the IESG, 
and advice from the IAOC.

In the RFC editor model, there are 3 types of substantive issues that 
will be important:

1/ Is a given component appropriately implementing the function, beyond 
the level of SLAs.
	. eg, is the proposed format change for publishing a document
	  in scope/out of scope

2/ Evaluating proposals for immediate term adjustments -- from the 
contractors, or from the community
	. eg., the community decides to only support Word docx formats

3/ Evaluating longer term evolution for RFC series implementation, 
perhaps in future contract cycles
	. eg., should a new stream be accepted into the RFC series?



Now, without the committee, either this is handled unilaterally by the 
RSE, or the IAB winds up intimately involved in the discussions in order 
to determine what needs to go out for community comment, and what needs 
input from the IAOC etc.

The Internet community has been fortunate to have RFC Editors who could 
handle this broad range of issue and provide rational guidance and 
decisions.

We have yet to identify a *process* whereby we can reliably identify 
such stellar individuals.  It seems wise to formalize a broader basis 
for supporting the solid candidates we are likely to find.



 > The opportunity to make significant changes only comes when the contracts
 > are up for renewal. As far as I can see, the new committee essentially
 > becomes a standing RFI/RFP requirements committee, and that sounds
 > close to being a delegation from the IAOC, not from the IAB.


I really don't see it as (only) a standing RFI/RFP committee, and I 
agree that would introduce a fair bit of tension into the system.  As I 
don't propose it as such, it's not meant to be a delegation from the IAOC.

Thanks,
Leslie.




> Leslie,
> 
> Let me try to respond at as high a level as possible, because
> although the devil may as usual be hiding in the details, we
> do need rough consensus on the principles.
> 
> We have running code for the flying-in-formation situation:
> the principles of what the Secretariat is supposed to do
> come from some approximation to IETF consensus as interpreted
> by the IESG and the IETF Chair (with some input from the IAB
> and IRTF about their requirements). But the contracts and daily
> operations are under the eye of the IAOC and IAD.
> 
> (Note: to say that this is running code is not to say it's
> perfect, but it hasn't crashed yet despite changing the engines
> in flight.)
> 
> Now, what you're proposing seems more complicated than this model.
> I think you're saying that the principles of what the RFCEd is supposed
> to do come from some approximation to community consensus as interpreted
> by the IAB (with input from the IETF, IESG, IRTF and independent
> opinion about their requirements). But another committee is created
> to make this requirements-interpretation an ongoing process on
> behalf of the IAB. And the contracts and daily operations are
> under the eye of the IAOC and IAD.
> 
> What bothers me a bit about this at first sight is that it potentially
> creates shifting sands among the requirements, and that is a poor
> basis for stable contractual operations. I'm a bit worried about
> that. Your proposed committee would have to be chartered quite
> narrowly to avoid that problem. I'm not sure how it's going to work,
> since once an N-year contract is signed, the only tuning that can be
> done is within the terms of the contracts, which are managed by the IAD.
> The opportunity to make significant changes only comes when the contracts
> are up for renewal. As far as I can see, the new committee essentially
> becomes a standing RFI/RFP requirements committee, and that sounds
> close to being a delegation from the IAOC, not from the IAB.
> 
>      Brian
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------


More information about the rfc-interest mailing list