[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt
leslie at thinkingcat.com
Mon Nov 15 08:54:14 PST 2010
Written form of my comments on the draft, covering my Monday night
plenary comments and subsequent discussions.
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.
1/ The top-level practical issue from Monday is the fact that this
document is not positioned as a discussion document. We (for any value
of we != Glenn ;-) ) don't have enough context to evaluate the merit of
the proposals, or the tradeoffs. (Figuring out if we agree it is
addressing the problem right).
Again -- I am not asking for a replay of Glenn's thought processes, nor
am I expecting us all to be RFC Editor experts. However, there are many
places in this document where it is difficult to distinguish between
steps needed for _any_ RSE to be able to get the work done, versus
Glenn's Good Ideas (GGI-tm).
(No offense meant to Glenn -- I'm sure they are good ideas; and I'm sure
the RSE will have good ideas; and so on and so forth. But for the
community to get behind them, we have to understand why they are good
ideas for all RSEs).
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
I.e., let's make sure we are discussing _only_ the parts that are the
"right problem" for now. There are many things that are included in the
document that seem to be getting ahead of the immediate problem -- I'll
note some, below. At any rate, this should not be
3/ It is not clear to me that the TRSE has to be the editor of that
discussion document: expertise in writing a discussion document is
what's needed here, and the TRSE expertise is _input_ to that document.
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 v1.5. At any rate -- it would be helpful to identify
areas of change from the proposed v1 RFC Editor Model, as opposed to
simply supplanting it with a text that is just different.
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).
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).
6/ IMO, the proposed RFC Editor stream is not actually critical to the
overall proposal and should be pulled out as a separate discussion. And
it should be a discussion, to ensure that it is perceived as necessary
and that the stream is set up in ways that the community actually supports.
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.
However, IMO it does not adequately highlight the RESPONSIBILITIES.
I have trouble with this:
"As the RSE and RFC Editor staff apply their specialized
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.
4.1.1 addresses this somewhat but:
Doesn't identify that the community can bring up issues
Seeks only acceptance from community, not input
And this discussion, right now, is the first instantiation of the
problem with that.
4.1.5 seems to write the community out of the function of contracting.
Which may be okay, but probably a surprise to some.
8/ This strikes me as being in the category of "idea to consider", but
it is not adequately motivated in the document, and definitely takes the
RFC series/editor to new areas:
4.2.4. Represent and promote the RFC Series to the outside world
The document notes that this could be expensive in time and resources
(yes!). IMO, it might be brought in to the realm of the germane if it
was reframed in terms of expected IMPACTs, instead of citing the rather
open possibilities of ACTIVITIES. I.e., what is the target outcome of
any such activity? I'm thinking -- the RSE is expected to raise and
maintain visibility of the RFC Series in the broader community than the
IETF. Period. Implementation details left to the RSE.
9/ I believe this must be doable, for contractual sanity:
The IAOC cannot on its own remove the RSE from office. If there is a
persistent concern about RSE contractual performance, it must be
reviewed by the IAB. The IAB must in turn consult with the RSAG.
I think that is in danger of solving the RSE executive authority
question by devoicing the IAOC. The IAOC holds the contract, and if
there are contractual reasons to remove the RSE, they have to be able to
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
Many of the responsibilities and tasks in this document are open-
ended. The RSE cannot accomplish all these tasks at the same time
with any reasonable level of resources. The RSE must manage the
extent of tasks, and their prioritization and execution. The RSE
must clearly communicate plans and expectations to the community and
1. Within 6 months of the RSE's appointment, or a date agreed with
the IAB, the RSE will publish an initial work plan and road map.
The RSE will indicate which initiatives and activities will be
focused on over the remainder of the first calendar year,
including their own activities and those of other RFC Editor
Components. These plans will distinguish between ongoing
operational duties and focused initiatives. In developing this
initial plan, the RSE will have had the assistance of the RSAG.
2. By 5 December each year thereafter, the RSE will publish a plan
and road map for the upcoming calendar year.
3. By 1 February each year, the RSE will publish an Annual Report of
the RFC Editor. This will include a review against the preceding
year's plans and highlight lessons learned that are reflected in
the new calendar year plan and road map. Summary statistics will
be included. The RSE may ask RFC Editor components to produce
relevant reports on request. The RSAG will review and comment on
the RSE's draft before the final annual report is published.
The RSE will issue a monthly report for delivery to the IAB and
publication to the community."
My reaction on reading this was -- "what would be in such a plan?". Is
this detailed operational, or high level strategic? The answer to that
question has a direct impact on the type of person that would be
appropriate for this role, so I think it's important to nail.
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.
12/ " Unless explicitly indicated otherwise, only full RSAG members
will provide direct counsel to the IAB or IAOC."
This will happen. Howevever, I don't believe it should be spelled out
as a right/requirement/expectation: otherwise, you have N different
opinions impacting the IAB and no way for the IAB to collate or rank
them. In terms of specified structure, the document should say that
the committee advises the IAB (if it does). All individuals should be
free to share their opinions with the IAB.
Yours to discover."
leslie at thinkingcat.com
More information about the rfc-interest