[rfc-i] RSE models

SM,
   thanks very much for your as-always thoughtful remarks.  A sprinkling of comments follows.
If I've missed an item that deserves attention, please let me know.

__
On Dec 23, 2010, at 5:28 AM, SM wrote:

> Hello,
> I am picking from Dave's message and not nit-picking on it.
> 
> At 12:26 03-12-10, Dave CROCKER wrote:
>> Management is always important for senior positions.  Having management when you
>> don't need it is terrible, as is not having it when you do.
>> 
>> Is someone who has overall responsibility for ongoing operation and enhancement
>> of an important document series primarily a "manager" or are they primarily a
>> "technician"?
> 
> That's a good question.  The discussion about the appropriate title, i.e. senior editor, manager, etc. distracts us from the issues that are expected to be addressed.
> 
>>     I hope the former, because that's the sort of person who
>>     worries whether all of the right pieces exist, whether they
>>     fit together properly, whether they are operating properly
>>     and how they could be made to be better.
> 
> If we expect the person to address systemic issues, the former is a better fit.
> 
> draft-kowack-rfc-editor-model-v2-motivations-00 is well written.  Although I may not agree with everything in the memo, it provides a public view of the RFC Editor Function which was lacking up to now.
> 
> I hope that Glen and the greater IETF will indulge me by allowing me to follow up with comments that are in line with IETF folklore.
> 
> From Section 1:
> 
>  "(Note to the reader: I use 'community' to refer to anyone
>   who participates in, or uses the output of, the technical,
>   organizational, and other discussions associated with the I*
>   entities.)"
> 
> This note sets the tone.  The greater IETF has the propensity to nit-pick about details.
> 
> In Section 2:
> 
>  "The RFC Editor (or 'Editor') must not allow anyone to have
>   inappropriate influence over, or 'capture' the Editor - using
>   it in his own interests.  This includes the Series Editor,
>   staff, contractors, unauthorized I* entities, individuals, or
>   groups.  For all substantive issues, the community must clearly
>   be in charge."
> 
> On my first reading of the document, I did not find how the community is in charge.  If it's through the REOC, I'll point out that the body is not representative of the community.

"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.

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 is unlikely that the Editor will be "used" for self-interest.  We all have dissimilar views about the Editor and we will strongly argue for that the RSE to be modelled in such a way.  It is easy for the Editor to be captured by the old boys club as they know about the RFC Editor better than anyone else.
> 
>  "Rather, each issue required deliberate review and analysis to
>   uncover its character and extent"
> 
> I'll open a parenthesis to mention that I view the Series as an archival series.  I agree that tackling the issues require sophisticated management and service design skills, not merely editing skills.
> 
> We have to take into account the context when RFC 5260 was written.  It took a modular approach.  There was a legacy system that had been running for years.  A transition from such systems is never easy.  Pushing for a "strong" RFC Editor would have been unpalatable.
> 
>  'The Series Editor is responsible for resolving policy issues and
>   providing "executive level management" of their implementation,
>   but does not have authority to assign resources.'
> 
> The question is: does the community want a Series Editor who can be a one-stop shop to resolve issues or does the community want somebody to see that the contracts are executed?  Resolving issues requires executive discretion to change priorities and reassign resources.

Please recall that the recommendations assume the same sort of delegation (to the contractor(s)) as in 5620.  So changing priorities and reassigning resources happens mostly within the Production Center by the Production Center Director, and only occasionally by request of the RSE.  I don't see how the latter is avoidable in the real world; special circumstances occur now and then, as they did when I asked Sandy for more of her time during the 2010 escalation procedure.

> In Section 2, it is mentioned that "This person must have no other interests".  A strict reading of that means that the one-third-time appointment (Section 6.1) isn't an alternative that can be considered.

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

> In Section 3.3:
> 
>  "The current success of the Editor and the Series is due
>   significantly to this historical fact."
> 
> In my uninformed opinion, the success of the Editor is due to the fact that the Editor can be technical when the circumstance warrants it, provide compelling arguments for an Editor decision in IETF style, together with their understanding of RFC Editor history.

Success has many fathers.

> In Section 3.3.2:
> 
>  "First, many initiatives should be carefully considered and
>   developed before they are taken to the community."
> 
> Yes.  But one should bear in mind that this is a contentious community.  Everybody speaks English but they do not speak the same language.  It is important that the Editor fully understands the community's way of doing business.

Absolutely.

> In Section 3.4:
> 
>  "I also responded to an author complaint by initiating an escalation
>   procedure."
> 
> Is that escalation procedure documented?

Not yet.  This is still an open action item.

> In Section 3.4.2:
> 
> "The RPC sought guidance because there was no previous policy
>  about who is the publisher of RFCs."
> 
> 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.

>  "No one had apparently been assigned responsibility for following
>   through after obtaining the ISSN."
> 
> No comment.
> 
> In Section 3.4.3:
> 
>  "Should the RFC Editor ever recommend that an author seek the
>   assistance of an outside editor, prior to submission; and if so,
>   based upon what criteria?"
> 
> If an Internet-Draft is badly written, one can only wonder why the Stream approved the publication.
> 
> In Section 4.1:
> 
>  "Finally, it is extremely unlikely, as has already been demonstrated,
>   that a motivated, qualified profession would accept that the reporting
>   structure is to be determined in the future."
> 
> Yes.
> 
> In Section 4.2.3:
> 
>  "[I-D.v2-overview] corrects this situation by disbanding the RSAG,
>   giving the REOC significant authority, and mandating IAB authority
>   for selecting REOC members."
> 
> That was not clear in draft-kowack-rfc-editor-model-v2-overview-00.

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

> In Section 5.1:
> 
>  "there is limited information to guide the novice's use of
>   and interpretation of the Manual"
> 
> Yes.
> 
> In Section 5.2:
> 
>  "As previously identified, the Procedures Manual, along with
>   the Style Manual, is the core device for ensuring quick guidance of
>   alternate editors in case of an unexpected interruption in service."
> 
> If it is a core device, it should have been attended to by now.

This is a good argument for having someone be responsible for this
sort of thing.

> In Section 5.4:
> 
>  "Enlarging this orientation to provide general guidance for how to
>   write technical documents could we an efficient was to assist both
>   authors and production center staff."
> 
> That largely benefits the IETF.  Is the IETF going to pay the cost of the enhanced training?

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.

> In Section 5.5:
> 
>  "We may eventually wish to certify such translations as being within
>   certain quality criteria."
> 
> For an archival series, it is best to have a single authoritative version.

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.

> In Section 5.6:
> 
>  "clusters of RFCs and their relationships"
> 
> Sandy commented on this [1].

She's right.  Another term needs to be used.

> In Section 5.9:
> 
>  "Community members tell me that they cannot produce complex
>   mathematical notation using ASCII, which they claim keeps
>   them from publishing certain RFCs"
> 
> Community members are very good at arguing their case. :-)
> 
> In Section 6.2:
> 
>  "Preparing for participation in email threads requires a
>   significant amount of time."
> 
> And an asbestos suit.

No HAZMAT capability?  Someone is losing their edge.

> In Section 7:
> 
>  "Furthermore, there is a great opportunity for the community
>   to find an experienced outsider who will drive new thinking
>   and debate."
> 
> if the experienced outside does not have an experience of the inside, the new thinking will be killed in the bud.  Let's take the ASCII wars for example.  Most people know that the discussion is a good vehicle for stress relief but the egg is not going to get hatched any time soon.
> 
> After reading the memo, I cannot help wondering what are the cost implications of the version 2 model.

Cost implications are very important.  When I began working on my recommendations, everyone
advised me to "get the ideas right first" and to investigate cost details later.  Fortunately, the
recommended model is reasonably consistent with historical practices, and costs should be fairly
reasonable. Nevertheless, the particulars still need to be resolved.

thanks again,
Glenn
___

> 
> Regards,
> -sm
> 
> 1. http://www.rfc-editor.org/pipermail/rfc-interest/2010-December/002049.html 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest