[rfc-i] RSE role

Ted Hardie ted.ietf at gmail.com
Wed Jan 19 15:13:00 PST 2011

Hi Ole,

A quick reply in-line.

On Wed, Jan 19, 2011 at 1:38 PM, Ole Jacobsen <ole at cisco.com> wrote:
> Ted,
> I agree with your points. As for being able to find someone from
> either inside or outside of the community, that's a different
> question, but the job is (some variation of) what it is so I
> guess the only way to find out is to announce it and see what
> happens.

This is clearly true, but I think a key point to make in that announcement
is that the job will both require publishing/editorial experience and developing
familiarity with the community if the candidate doesn't already have
it.  They should
know that we are willing to be patient while that develops, because we
want the community to participate in the series' evolution.  The job
is not to come
in and shake things up.  It is to learn the community  (if they don't
know it) and use
their experience to help it move forward on *its* goals.

The guidance we're looking for includes suggesting goals and parallel series to
look to for inspiration, as well as a solid sense of what's implementable in our
context and what is not.  There's a lot of scope for leadership in
that, but knowing
our context will be a part of any successful effort.  Ideal remains someone with
both sets of experiences already, because there is no dead time, but the key is
that candidates must understand that's where they need to end up.

best regards,


>I don't get a sense that a lot of "respected members of
> the community" are jumping up and down to take this job.
> Ole
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: ole at cisco.com  URL: http://www.cisco.com/ipj
> On Wed, 19 Jan 2011, Ted Hardie wrote:
>> Some comments in-line.
>> On Wed, Jan 19, 2011 at 6:28 AM, Russ Housley <housley at vigilsec.com> wrote:
>> > Glenn:
>> >
>> >> there are many, many aspects of RFC Editor and RSE work that
>> >> depend upon expertise in editorial and publications techniques
>> >
>> > You keep saying this, and I remain unconvinced.
>> >
>> > I have said this to you in less public places, and I am now
>> > repeating it in this very public place.  From my perspective, the
>> > most important role of the RSE is cross-stream coordination and
>> > policy.  The policy portion involves leading discussions with the
>> > whole community, and this can best be done by a respected member
>> > of the community.
>> >
>> So, I think the key point here is that cross-stream coordination role
>> that the RSE has is specific to editorial and publications points,
>> since content has been explicitly ruled out.  Leading discussions on
>> those points actually requires pretty significant expertise with them,
>> or the policy that's returned may be unimplementable and/or way out of
>> the mainstream.
>> Ideal from at least my perspective is someone who has both that
>> experience and IETF experience, but that's a pretty limited set and
>> the number of hours/pay may well make it the null set.  So we're left
>> with the question:  is it easier to grow a member of the community in
>> this domain, or easier to get someone with this domain knowledge to
>> build a reputation inside the community?  As long as we're clear that
>> we want the intersection at the end of the day, I think we can reach
>> this point, but it will take time either way.
>> My personal take is that absent the ideal case, it will be better to
>> hire someone with publication experience and grow their knowledge of
>> the community they will serve.  The risk in the other direction is
>> that we will have a respected member of the community who becomes
>> increasingly familiar with the way we already do publication, with
>> little to know exposure to how others do it.  That might limit our
>> ability to evolve the series to meet new needs.
>> To take a small example:  I've suggested in the past that we provide
>> translations of the boilerplate in the RFCs to eliminate a hurdle to
>> providing translated specs (something we permit and might choose to
>> encourage).  Having limited outside experience in this, I have no clue
>> whether this is common or perceived as a good idea by other technical
>> publications.  There are some obvious policy issues (does the legal
>> boilerplate need review by international lawyers as well as
>> translators?), but there are also some production issues:  if we
>> provide it in plain text files is that enough?  Do we need to provide
>> templates or tools for this to be useful?  What are the costs to
>> maintain these as we update our boilerplate etc?  (If the answer is we
>> need to provide CSS and HTML snippets because everyone else uses that,
>> we have one cost; if everyone who wants to provide this uses a
>> different tool, the cost will be higher).
>> I don't want to rathole on the proposal, but to highlight that there
>> are elements even in that relatively simple piece where
>> editing/publishing experience in a reasonably comparable series would
>> be useful.  Harald used to say "A pair of data beats a full house of
>> supposition", and I think experience does the same--and the relevant
>> experience hear covers both the policy question and the actual
>> production.  The editor/publisher experience is a demonstration that
>> they know how policy matches to implementation, and implementation
>> remains a pretty important point to all our work.
>> best regards,
>> Ted Hardie
>> > To me, expertise and experience with editing an publications is
>> > _much_ less important.  So much less that it does not even make
>> > the radar screen in comparison.
>> >
>> > Russ
>> >

More information about the rfc-interest mailing list