[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt
dhc2 at dcrocker.net
Wed Nov 17 21:37:15 PST 2010
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
> 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
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
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.
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
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
Current proposal not (yet) sufficient to cover a "broad" RSE
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
Presumption that community has been involved in contracting;
Concern that RSE outward functions (promotion) will be
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
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.
More information about the rfc-interest