[rfc-i] Some questions on the model and the motivations

Olaf Kolkman olaf at NLnetLabs.nl
Tue Dec 21 12:32:11 PST 2010

Glenn, Colleagues,

The hallway discussion that I am aware of seems mostly be about the scope of responsibility and the level of responsibility that an RSE need to have.

That discussion made me read the motivations document with a specific point of view. With the caveat that I've read the motivations document only once after first seeing it last week here are a few are a few questions for which I did not manage to extract a crisp answer. These questions are mostly for Glenn, to get some documentation on where he is coming from. It may be that others have specific ideas here too. 

I've tried to provide some context by introducing some of my thoughts and observations, followed by some concrete questions. I am hoping for concise answers to those questions. 

1) Much of the discussion is about the scope of authority and the role of the RSE. What follows are some questions that I believe have some implicit answers in the motivations document but of which I would benefit getting a more explicit answer on.

1.a) Suppose we would not be able to find an RSE. What would the effect on the series and what would the community notice in weeks, months, and years?

1.b) Suppose we would redesign the model to get rid of the RSE, what responsibilities would need to be assigned ownership, where would you assign those responsibilities in the current 'greater IETF'?

2) Model V2 and the observations document argue strongly for the RSE being independent from the production center and Publisher. In the overview document (secion 2) you postulate a design choice that the RSE must maintain a balance between demands of RFC production and Series development.

2.a) what are the tools to achieve that balance?

2.b) Does this involve Production and Publishing resources? And how are those resources negotiated?

3) You argue for an editor with a strong editorial background. On the other hand (apologies, this is a bit of a hyperbole) one could argue that Postel, Reynolds, and Braden did not have such editorial background when they started the job. Besides, for the case (3.4.2) which you use to argue there is a need for person with publication background (the ISSN) the observation that the ISSN was not available was not made by the RSE but by involved community members. The value add, as I read from the observations, was that the RSE had a librarian friend in the rolodex.

I also observe that although you yourself have some background in 'our community' you are not what people call a 'grey beard' IETF-er and have had to go, and are probably still going, through the learning curve of dealing with this community. That to me seems to be an important piece of running code.

3.a) How long would it take somebody without any background on the IETF but with solid publication experience to get used to us? v.s. How long would it take somebody from our community to get to understand the publication aspects?  (Substitute "How long" with "How likely" or "How difficult", I know this is going to be a very subjective and hard to quantify answer). 

3.c) Are there any methods by which the job can be made attractive for a relatively senior professional from our community?

4) Initially the model was created to make sure we (the community, through the IAB and the IAOC) could control cost and continuity of the series. Continuity has been established mainly because our competent folk from ISI moved to AMS when AMS won the production center bid. While that removes the immediate angles and continuity risks there I don't think that model v2 has taken a very different stance on how continuity is provided. That is, in version 2 of the model providing continuity is still centered around building a style manual and a production handbook and that sort of operational documentation. 

4.a) What are the biggest continuity risks going forward with the RFC Series and does the model address those?

4.b) What are the concepts in the model that, if not achieved or implemented successfully, endanger the series, and why?

That's it for now...

--Olaf (no hats)


Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20101221/2ca95e6a/attachment.p7s>

More information about the rfc-interest mailing list