[rfc-i] RSE models

[sm at resistor.net (SM)]

Hi Glen,
At 00:32 03-01-11, Glenn Kowack wrote:
>"The community is in charge" is a principle that infuses all my 
>recommendations.  The community may thus hold the RSE and REOC's 
>feet to the fire if either is unresponsive to community interest.

The community can only "complain" on the mailing list or go to the 
microphone.  I'll adapt a few lines from one of the BCPs to give you 
an idea of what I consider as holding feet to the fire:

  "The RSE is directly accountable to the Internet community for the
   performance of the RFC Editor Function ...

   If a member of the Internet community questions whether a decision or
   action of the RSE has been undertaken in accordance with operational
   guidelines, or questions whether the RSE has created and maintained
   appropriate guidelines, he or she may ask the RSE for a formal review
   of the decision or action.

   If a member of the community is not satisfied with the RSE's
   response to his or her review request, he or she may escalate the
   issue ..."

That may be similar to the escalation procedure that was used last year.

>Side point: In my recommendations, the charge of the IAB is to 
>create an REOC that will be structurally oriented toward community 
>opinion. I'm not sure if I see your argument here; are you saying 
>this cannot be done?

It's doable if the REOC operates in a transparent manner.  I'll be 
convinced when I see the REOC that is "structurally oriented toward 
community opinion" implementation.

>By "no other interests" I only meant "conflicting interests".  I was 
>unclear about that -

Ok.

> > Isn't the RFC Editor or rather the RFC Series Editor the publisher of RFCs?
>
>I did not get an unambiguous answer when I asked around during early 2010.

The choice of name for the publishing aspect in RFC 5620 might have 
led to this ambiguity.  There can be some inconsistencies if 
draft-kowack-rfc-editor-model-v2-overview follows Section 3.4 of RFC 
5620 as the first version provides more than one alternative.

>That's right.  Hopefully, the 'Motivations' document has taken care of that.

Yes, it did.

>I'm really embarrassed by that para above.  It should have read:
>" ....write technical documents could *be* an efficient *way* to 
>assist both..."
>And, re "who is going to pay": this remains to be determined.  My goal was
>to bring the issue to light as a future possibility.

Ok.

>Absolutely.  Still, if it were to come to pass that outsiders were 
>starting to translate
>RFCs, we might be able to facilitate their work, improve quality, 
>reduce errors, all
>at little cost to us.

There are already some RFCs that have been translated.

>No HAZMAT capability?  Someone is losing their edge.

:-)

One might conclude from RFC 5620 that the contract-based model is the 
better way to ensure the continuity of the Series.  Some people might 
overlook that it worked because "we" took the same people and put 
them under a different umbrella.

During the discussions, there was views in favor of sticking to the 
40-year old model and other views for a fresh approach by bringing in 
an outsider with publishing experience.  There were discussions about 
ability to solve problems which got intertwined with the authority 
(see advise and consent for a better picture) to set the direction 
for the Series.  One alternative is to pick a model for the short 
term which borrows from BCP 101.  There are other alternatives such 
having a RSE that can fit in the shoes of the RFC Editor (obsoleted 
by RFC).  It is premature to say which model is better.  Only time can tell.

Regards,
-sm