[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt

[Dave CROCKER]

Andrew,

On 11/17/2010 4:10 AM, Andrew Sullivan wrote:
>     "All of this stuff
> should be taken out; here's a whole bunch of stuff that isn't includes
> but that should be included; and we need to make a stark choice
> between two options, so please lay that out," is in fact a message
> about _content_, not form or style.  I've seen more than one of those.

Assuming they did not merely say "start over", can you cite them?  Apologies for 
having missed these thoughtful constructive messages from different folks.

I took your own, previous posting in rather stark contrast to the type I was 
commenting on.


> If you have problems with what Leslie said, fine, but I don't think
> it's cricket to make insinuations about everyone who's asking
> questions.

Perhaps your audit of the comments at the microphone and on the mailing list 
archive is different from mine.


> As I already said, I can't _tell_ whether the recommendations are
> acceptable, because the premises that would actually allow me to
> understand their reasoning -- the experiences of the TRSE -- are not
> outlined (or anyway, not in a way that I managed to discern).

His mandate was to formulate recommendations, but now he's being told to 
formulate a transcription of his thinking.  Different task.  Maybe the IAB 
should have specified "provide a discussion about the issues and tradeoffs that 
might be relevant to the RFC Editor and the RSE."  But they didn't.  They need 
to hire someone, not have several years more of discussion.


>> Instead the dominant feedback Glenn has gotten is that folks won't
>> provide substantive feedback because he didn't show his work or he used
>
> My issue was not "didn't show his work".  I can't tell whether Glenn's
> is a reasonable recommendation.

That's the part that is strange.  It is not as if any of us lack experience 
within this community or especially with the RFC process.  Apparently a tutorial 
is needed about the RFC Editor, for those reviewing the proposal?

Does the proposal specify functions that are unfamiliar?  Do you think those 
functions do not need to be performed or that they should be performed elsewhere?


> There's a reason the first round of
> the RSE hiring failed, and I think it's that the job is not a
> reasonable one.  The job as now proposed might be a reasonable one,
> but it might well be solving the wrong problem.

Describing a job or a service like the RFC Editor can, perhaps, primarily be 
cast in terms of solving problems, but usually it is in terms of constructive 
work that delivers something useful.

This is an on-going service.  Problems arise, but the "problem" the RFC Editor 
is to "solve" is production of RFCs, archiving them, and making them available 
to the community.  The other "problem" is looking for opportunities and 
requirements for enhancements. What other sort of problems are you thinking 
should be cited and solved?


>  We would be able to
> tell if we had the evidence that said, "I experienced _x_ and
> therefore I recommend _y_."

And wouldn't it have been nice for the community to share these documentation 
requirements with the TRSE, sometime in the last 8 months?

But still, note that other than your drawing the distinction between two types 
of RSE roles, posters have not risked offering their own views of choices or 
preferences.  Glenn gets to guess what folks will find useful.



Since some folks have vigorously rejected my assessment of commendtary about the 
TRSE's recommendation, I thought it might be helpful to provide my own, informal 
audit of the 75 posting topics in the two weeks since release of the Overiew (3 
November).

This is meant to be reportorial rather than analytic; if I have gotten something 
factually wrong or incomplete, please simply provide new or replacement text or 
tell us what text should be deleted.


RFC-Interest list:


12  D. Crocker   - Discussion about RSE stream;
                    Comment on "broad" vs. "narrow" RSE labels and implications;
                    Concern about the generic nature of feedback and guidance.

10  B. Carpenter - Considering whether an "RFC Editor stream" is needed;
                    Discussion of substantive aspects of Independent stream
                    handling;
                    RSE role in non-technical content;
                    Support for "broad" role described in Overview;
                    Desire for proposal to expand discussion about community
                    process (including RSAG).

10  P. Hoffman   - Whether to have an RSE stream;
                    Remove History section;
                    Role of RSE in non-technical content;
                    Call for TRSE to document experiences;
                    Some support for estimate of weekly hours cited in Overview,
                    or half that with no effort at enhancement.

  6  J. Touch     - Nature and process of Independent Stream review.

  6  L. Daigle    - Is right "problem" being addressed;
                    Proposal not case as discussion;
                    Suggest focusing only on items needed to spec a job
                    sufficiently to hire an RSE;
                    Who should edit discussion document.
                    What version of the RFC Editor Model the TRSE proposal
                    represent.
                    Current proposal not (yet) sufficient to cover a "broad" RSE
                    role.
                    Also needs to see a "narrow" proposal;
                    Document (and proposed structure) size;
                    Inadequate consideration of ramifications;
                    RFC Editor stream;
                    Requirement that RSE authority not be unilateral;
                    Need to clarify relationship to community, including
                    initiative;
                    Presumption that community has been involved in contracting;
                    Concern that RSE outward functions (promotion) will be
                    mishandled.
                    IAOC must be able to fire RSE.

  5  SM           - Small editorial changes suggestions;
                    Request for clarifications and examples from specific
                    portions of the proposal;
                    Question about whether changes to existing RFCs are required;
                    Preference not to have RSE stream;
                    Discussion about additional streams.

  4  O. Jacobsen  - Role of RSE in non-technical content.

  4  A. Sullivan  - Toss out history;
                    Distinguish narrow vs. broad RSE;
                    Document TRSE experiences, to justify choices;
                    Beefing up proposal this way will make it 'complete' as a
                    proposal for a "broad" RSE job.

  3  B. Hinden    - Consdering whether an "RFC Editor stream" is needed.

  3  G. Kowack    - Responses and clarifications to SM questions.

  1  J. Halpern   - Response concerning who should author comments on TRSE
                    proposal.

  1  T. Hardie    - Different RSE implications between 'admin' and 'senior
                    technical profession'; reference to contract management.

  1  T. Hanson    - Participation in non-technical content thread.



d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net