[rfc-i] RSE models

[sm at resistor.net (SM)]

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.

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.

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.

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.

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.

In Section 3.4:

   "I also responded to an author complaint by initiating an escalation
    procedure."

Is that escalation procedure documented?

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?

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

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.

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?

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.

In Section 5.6:

   "clusters of RFCs and their relationships"

Sandy commented on this [1].

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.

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.

Regards,
-sm

1. http://www.rfc-editor.org/pipermail/rfc-interest/2010-December/002049.html