[rfc-i] RSE models
sm at resistor.net
Wed Jan 5 10:12:58 PST 2011
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
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 -
> > 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
>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.
>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.
More information about the rfc-interest