[rfc-i] RESEND: RFC Editor Model Version 5 and revised RSE SOW
olaf at NLnetLabs.nl
Sat Apr 25 23:56:34 PDT 2009
On 25 apr 2009, at 23:25, SM wrote:
> Hi Brian,
> At 13:08 25-04-2009, Brian E Carpenter wrote:
>> That is far too weak an approach IMHO. Firstly, what on earth does
>> If the Series Editor decision is not satisfactory, then the the
>> matter must be registered with the RFC Series Advisory Group.
>> actually mean? Either an appeal decision is appealed to the RSAG, or
>> it isn't. In fact, it can't be, since the RSAG isn't superior to
>> the RSE. So this adds no value. Also, the sentence is in the passive
>> tense - who decides a decision is unsatisfactory, and who causes the
>> 'registering' to occur? The whole process is wishy-washy, and doesn't
>> give the oversight body *any* power whatever to intervene in bad
>> decisions (except by causing the RSE to be fired, I suppose).
Correct. Subramanian explains it better than I could have done :-) :
> Version 5 does not hold its ground from a process perspective. I
> presume that it was written in such a way to be wishy-washy. The
> purpose of the RSAG (from the Model) is to provide guidance. It
> doesn't have any formal oversight role; the IAB retains. The RSAG
> is required to make the dispute and its advice publicly available.
> That's the only departure from the usual role of an advisory body.
There is indeed little that can be done to revert an RSE decision
except firing the RSE if there is a pattern of bad policy decisions
and _not_ taking advice from the RSAG.
Essentially you can share 'power' between the RSE, RSAG, and IAB in
various ratio. This variety errs on the side of giving most to the RSE
in a way that allows her to execute decisions in a timely manner. This
keeps the RSAG at a little distance, but allows them to give (public)
About 'who causes the registering to occur'. An important detail
indeed. I would say any party that is discontent with a decision. You
don't want that to flow through the RSE.
Also, what was implicit to me is that the registration of complaint is
supposed to be publicly available, including the advice.
>> There's no need to reinvent a new form of wheel. Just cut and paste
>> from section 3.5 of RFC4071. That defines a very clear procedure with
>> effective oversight.
> The RFC Editor Model is being viewed in contractual terms. That
> doesn't fit within the responsibilities assigned to the role. I
> don't think we should have policy decisions go through a process
> designed for administrative support. Your proposal at least
> provides a clear resolution path.
Who is "You" in "Your proposal", or, which proposal do you mean?
> It will be an awkward situation if the RSE is fired as the RSAG, as
> an advisory group, cannot step in then. There is a lot that has
> been left unsaid in the Model.
_Personally_ I am of the opinion that in those sort of cases it is
probably better to leave the situation a little under-specified, I
believe that in those cases you want the parties involved to have some
room to improvise towards a good solution. This in contrast to an
engineering specification, where you expect that the software cannot
improvise for a good outcome.
That is not to say that, if you can think of these sorts of problems
in generic terms, you shouldn't try to provide guidelines.
> The Model might be adopted because of the deadline and "fixed" once
> the RFC Editor structure is operational.
I hope that "Version 1" in the title is not there 'pro-forma'. If we
learn during the next few years we should be able to get to a "version
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20090426/16aafa79/PGP.bin
More information about the rfc-interest