[rfc-i] Some comments draft-kowack-rfc-editor-model-v2-00 and a suggestion

Leslie Daigle leslie at thinkingcat.com
Tue Nov 16 15:27:50 PST 2010


Hi Andrew,

I think this is a very thoughtful proposal for moving forward, but I, 
for one,  can't quite agree that the current document is the broad 
proposal.  As I noted in my detailed comments, I think it actually needs 
more work to adequately capture the broad function (apart from agreeing 
with you that the document does not give the background to be able to 
assess the motivation of it).

So, it would not be a case of writing the "narrow" proposal to compare 
to this:  I believe it would require writing 2 separate documents.

I'm not entirely sure we need to.

Leslie.

Andrew Sullivan wrote:
> Dear colleagues,
> 
> This note is intended to do two things.  First, it is a more complete
> statement of some remarks I made at the mic the other day.  Second, it
> makes a suggestion about trying to resolve an apparent fundamental
> issue in the current discussion.  I put headers on the two parts so
> that if you don't care what I think about this draft but want the
> suggestion, you can skip ahead.
> 
> 1.  Comments about the draft
> 
> a.  History
> 
> I think almost all of the historical claims in this draft could be
> removed, and the draft would be better for it.  I have to agree with
> some others that expansive claims such as
> 
>    The RFC Series is the Internet technical community's official medium,
>    through which it communicates with itself and the rest of the world.
>    6,000 RFCs since 1969 comprise one of the most extensive and
>    influential technical series in history.  Without openly available
>    RFCs, the Internet could not have been built, could not operate, and
>    could not continue its remarkable advance.
> 
> are at least distracting and at worst nonsense.  (Any time I see a
> counterfactual impossibility claim, for instance, I immediately want
> to make up the world in which it is false.)  Cut it.  If you think you
> need background, it is enough to provide a list of previous RFCs on
> the topic, that the hiring process that came out of them didn't work
> as planned, and that the current text provides a proposal for how to
> alter RFC 5620 so that the next attempt to hire someone will succeed.
> As nearly as I can tell, that's all the background needed to
> understand why this draft exists.
> 
> b.  Two models
> 
> After the plenary, it seemed to me that it could be extremely valuable
> to outline the two broad models for the RSE in the end.  One is what
> we might call the narrow construction.  In this model, the RSE is the
> senior line editor, with editorial policy and so on completely under
> the control of some other body or bodies.  Note that this is very much
> in line with the notion in RFCs 4844 and 5620 that there is an RFC
> Editor _function_, which might happen to be performed by several
> different people.  The second is what we might call the broad
> construction.  This is effectively the model in the draft now: the RSE
> has a senior management function, and broad chunks of editorial policy
> fall to it.  This amounts to a senior management role for the RSE.
> 
> c.  Motivation
> 
> In contrast to the history outline, the actual experiences of the TRSE
> over the course of his tenure seem to me to be the sort of thing that
> nobody else could provide.  Those experiences would be valuable
> evidence with respect to the proposals.  For instance, the draft
> recommends that the broad construction of the RSE is the right one,
> and makes recommendations about how to alter the RSE job so that it is
> a more effective instantiation of that broad construction.  But there
> is not enough evidence in the draft for a reader to evaluate whether
> the broad construction is the right one.  Neither is there enough
> evidence in the draft for a reader to evaluate whether the specific
> recommendations would actually achieve the desired goal.  So more
> reporting of those experiences, and analysis of them, would be a
> valuable addition to the document.
> 
> d.  Something valuable in the draft
> 
> The draft as it stands makes a particular recommendation for how to
> restructure the RSE job along particular lines.  I think that, if one
> accepts the broad construction of the RSE, the suggestions are pretty
> good.  As others have noted, RFC 5620 sets up the RSE in such a way
> that the job can't really be done by anyone who wants it, because it
> has responsibility and no authority.  Nobody we would want to do the
> job will accept it, and the responsibility without authority is
> presumably part of the reason.  The very fact of having a TRSE is
> evidence of this, and I think that if we accept the broad
> construction, we should proceed with something like the
> recommendations in this draft.
> 
> e.  Overall structure that would be useful to me
> 
> If the above is right, then the draft needs to be about two things:
> why the broad construction is the right one for the RSE, and what the
> specific job description should be in that case.  I think the draft as
> it stands has the latter (in section 4), and not really the former.
> As it stands, the draft also contains some other material irrelevant
> to these two categories.  I suggest that all of that should be
> removed.
> 
> 2.  Suggestion
> 
> There have been, in the discussion on the list and at the plenary,
> several strong claims about whether the broad construction or the
> narrow construction is the right way to think about the RSE.
> 
> I think the changes I suggested in part 1 of this message would make
> for a complete proposal for the broad construction.  
> 
> Often, in the IETF, we like to have a sort of scratch alternative
> proposal in order to evaluate whether the direction we're going is the
> right one.  I therefore suggest that those who are sure the narrow
> construction is the right one ought to provide the arguments why it
> is, and also provide a sort of point-form job description to compare
> with the one in the draft.  The reason for this is that there seems to
> be a longish list in the draft of functions for the RSE, and a
> competing proposal would need to say whether the RSE would do those
> things, whether someone else would do those things, or whether those
> things just aren't needed or actually ought not to be done.  I simply
> can't tell, from the discussion so far, how the broad and narrow
> constructions stack up against one another.
> 
> Best regards,
> 
> Andrew
> 

-- 

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


More information about the rfc-interest mailing list