[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:45:14 PST 2010
On reviewing the list activity, I re-read your lengthy note in some detail and
found a number of points worthy of asking for clarification:
On 11/15/2010 8:54 AM, Leslie Daigle wrote:
> 0/ My closing remark on Monday was about clarity of whether the document (or any
> part of it) is addressing the right problem, or if it is addressing the problem
> right. I think there is a bit of both going on.
Please elaborate. If this is the wrong 'problem' what is the right one?
If the problem should be addressed more 'correctly' what does that mean?
> 1/ The top-level practical issue from Monday is the fact that this document is
> not positioned as a discussion document.
You should ask the IAB/ why they gave him the wrong assignment.
> 2/ Recognizing that the target is to have a document that allows the kickoff of
> the process for finding the RFC Series Editor (non-transitional), I strongly
> suggest that the base document focus only on areas needed to make that happen.
> . clarity about executive authority is cited as a requirment
> . plans to have the RSE travel to NANOGs etc -- probably not so much
There is a small problem that hiring a longer-term RSE requires having some idea
of what the structure and responsibilities are surrounding them.
So if you believe there are practical boundaries to what the TRSE recommendation
should be, can you supply more than a couple of examples? Perhaps others will
think the boundaries should be elsewhere; we won't know that until we see your
specifics (and theirs.)
> 4/ In general, I do not believe this document, or the issues that need to be
> addressed in this discussion, represent v2 of the RFC Editor model. Perhaps
I was thinking more like v1.66667.
> 5/ I also commented at the mic on Monday that this document and the proposed
> structure is either too big or too small.
> By that I mean: I think it alludes to an RSE activity that is much bigger than
> the role envisioned as the key piece to allow the RFC Series to continue in the
> light of the new RFC Editor model. (It's too big).
I've reread this last text a number of times and can't quite figure out what it
means. Please clarify.
> At the same time, I don't think this has enough consideration of all the
> ramifications and implications of the suggestions, nor does it give the RSE (or
> the other components of the RFC Editor model) enough of a basis to fully realize
> those directions over time. (It's too small).
It is unlikely that many suggestions made by anyone have enough consideration of
all the ramifications and implications.
But since you are citing the problem here, it implies that you know of specific
ramifications and implications that were probably missed but are important not
to miss. What are they?
> 7/ Section 4.1 executive-level management
> This details the rights of the RSE as an executive, bringing in the particular
> nature of the Intenret technical community, which is quite useful given that it
> was cited as a major impediment to understanding the intended RSE role in the
> first RFP round.
"Rights"? I thought this was about responsibilities and authorities. Are we
really that worried the RSE will be abused by the Internet government? (The only
occurrence of the word 'rights' in the proposal is about Copyright Notice...)
As for the reference to a major impediment, again I can't figure out what you
are referring to. Please clarify.
> However, IMO it does not adequately highlight the RESPONSIBILITIES.
There are a slew of bulleted lists in 4.1 and they are quite explicit and in the
classic style used for describing job responsibilities. What is inadequate
> I have trouble with this:
> "As the RSE and RFC Editor staff apply their specialized knowledge,
> they will develop unique perspectives and insights. They must be
> free, and encouraged, to shape those insights into their own unique
> vision for the RFC Series. "
> It's one thing to bring them to the table, it's another to cause the community
> to read it in the news. In my opinion: the RSE needs executive authority to
> carry out the work, but this does not extend to unilateral authority to change
> the series.
I am pretty sure that neither Canadian and American English permit interpreting
that text to have that meaning, since there is nothing in that text that
discusses authority, except the authority for shape a vision.
As for 'read it in the news' I also missed the text that discusses how the
vision is communicated. Perhaps you can point it out? Or explain why that
dramatic and singular an interpretation of the text was warranted?
> 4.1.5 seems to write the community out of the function of contracting. Which may
> be okay, but probably a surprise to some.
You would like contracting to be conducted on an open IETF list?
Since I'll guess that that's not what you meant, please explain what practical
activity you have in mind?
> 10/ This is another area where it might be helpful to capture the intended
> outcome, not the specific mechanical activities:
> "4.3.1. General Planning, Prioritization, and Reporting
You are asking about the "intended outcome" for:
> the RSE will publish an initial work plan and road map.
> initiatives and activities will be
> focused on over the remainder of the first calendar year,
> a plan
> and road map for the upcoming calendar year.
> 3. By 1 February each year, the RSE will publish an Annual Report
Each of these strike me as standard items to request. Are you really unclear
what their purposes are?
> 11/ IMO, this insulates the RSE -- in a bad way: "In this way, the RSAG ensures
> the RSE is aware of community opinion and requirements." It needs to be balanced
> by ensuring the RSE talks with the community.
What wording changes would satisfy you?
More information about the rfc-interest