Re: RFC Editor Structure

[Frank Ellermann]

Olaf Kolkman wrote:

> The proposed model is posted on the RFC interest list, see
> http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html
> and made available through
> http://www.iab.org/documents/resources/RFC-Editor-Model.html

Thanks for info.  Some quick observations while looking at the
picture of your model:  You don't cover the rather convoluted
interactions between IESG and "ISS", to fix that please sort
the "stream" columns like that:  IAB | IETF | community | IRTF.

What does "selected by the community and confirmed by the IAB"
actually mean, is it the same idea as for area directors, i.e.
NomCom representing a random set of volunteers from visitors of
three out of five recent IETF meetings ?

Why should there be two persons - new "ISS" and new RFC-editor -
instead of one ?  In what way would a new "ISS" selected by the
NomCom be really independent from IETF / IESG considerations,
which is the whole point of this "independent" escape hatch as
noted two years ago in the RFC 4844 discussions by John Klensin ?

RFC number assignment should be the privilege of the RFC editor,
not of some "outsourced" RFC production entity.  This used to be
great magic in the past, and it is a completely subjective magic.

Moving some "RFC publisher" functions to the IETF secretariat
could make sense, if that is about maintaining a high traffic
Web server with tricky forms.  But the quality of some IETF Web
server forms is not yet up to the standard of some RFC editor
forms.  Working Web forms can't be expensive, please don't try
to fix it if it is not broken.

 Frank

_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Bob Braden]

Dear hmdmhdfmhdjmzdtjmzdtzktdkztdjz,

You wrote:
  *>
  *> Thanks for info.  Some quick observations while looking at the
  *> picture of your model:  You don't cover the rather convoluted
  *> interactions between IESG and "ISS", to fix that please sort

See RFC 3932.

  *> the "stream" columns like that:  IAB | IETF | community | IRTF.

I am not aware of any implied ordering, and I don't know
what it would mean.

  *>
  *> RFC number assignment should be the privilege of the RFC editor,
  *> not of some "outsourced" RFC production entity.  This used to be
  *> great magic in the past, and it is a completely subjective magic.

It is not a "privilege", but a duty.  And not exactly magic, but the
community likes it that RFC 2822 was an update to RFC 822, for example.
Not an accident, though Joyce used to like to pretend it was.

The RFC Editor organization believes that RFC number assignment is
inextricably bound with the production process, so it would make
little sense to separate these functions.   This assumes that
the RFC publication model continues to use late binding for RFC
numbers, as it always has.  Another choice (which I believe has
some serious flaws) would be to change to early RFC number binding --
say, RFC numbers are assigned by the IESG before the document
enters the publication process.  The IESG could go as far as it
wanted towards structuring the number space (and how long would
it be before a Dewey decimal numbering scheme appeared?).

Bob Braden
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Brian E Carpenter-2]

Hi,

1. What's the funding model for the "Independent Stream Supervisor"?
That's not a job title that is very inspiring, and if it's a volunteer
position, it would seem very unlikely to me that we'll find reliable
and conscientious individuals willing to do it in the long term.
I don't see it as comparable to an unpaid Editorship of an academic
journal, for example, unless it is described in much more exciting
language. But it also seems hard to justify as a funded service
on its own. "Expenses to support the administrative operation of
the Independent Stream Supervisor selected in this manner would
be part of the IASA budget." Well, that is a very explicit extension
of the scope of IASA beyond IETF activities. I'd want to see a
consensus call on that.

2. Also re the Independent Stream: "...no changes to the Editorial
Board are being proposed." Let's discuss that. I don't like the
current degree of secrecy around the way the EB reviews independent
submissions. Especially if we end up spending IASA money explicitly
for this stream, I'd like to see all EB reviews being made public.
People who want to publish via confidential peer review have lots
of other places to try.

3. I find it hard to see any advantage of making the "RFC Editor"
job independent of the contractor for the "RFC Production" function.
Funding it as a separate activity seems to add cost and complexity
for no particular reason. I think it should just be a part of the
"RFC Production" contract, with some conditions to ensure
responsiveness to the community.

4. I suggest that total efficiency will be greater if the
RFC Publisher function is part of the Secretariat IT service,
which already includes web site support and I-D publication.

5. The responsiblities of the RFC Publisher need to include
maintenance of the various plain text and hyperlinked indexes
currently provided at rfc-editor.org. I believe this strengthens
my previous comment.

    Brian
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Bob Braden]

 
  *>
  *> 2. Also re the Independent Stream: "...no changes to the Editorial
  *> Board are being proposed." Let's discuss that. I don't like the
  *> current degree of secrecy around the way the EB reviews independent
  *> submissions.

Brian,

RFC 4846 (July 2007, Klensin & tHaler) established the rules for
handling reviews of independent submissions.  In general, the RFC
Editor has been attempting to follow that document since it was
published.

Originally, the RFC Editor used the academic model, in which reviews
are (of course) shared with the author but not made public.  RFC 4846
generally favors posting of reviews, although in fact it does not
absolutely require it; see section 7.1.  In any case, the RFC Editor
intends to follow the general thrust of 4846 by posting reviews on our
web site, and we began the process of making that happen.
Unfortunately, higher priority issues intervened, and we never got back
to complete the task.  Thanks for your comment, and we will try to
remove the veil of "secrecy" ASAP.

Bob Braden


     Especially if we end up spending IASA money explicitly
  *> for this stream, I'd like to see all EB reviews being made public.
  *> People who want to publish via confidential peer review have lots
  *> of other places to try.

_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Brian E Carpenter-2]

Bob,

Yes, I'm aware of the history here and I'm only repeating
my previous opinion on this. I have to say that over the years
I've come to greatly prefer the fully open model of review,
even if one does get roasted in public from time to time.
The academic model of confidential review is a good way to
filter out substandard work at an early stage, but public
review seems to be the best way to get high-quality documents
at the end of the process. I'm not sure why this community
would want to do it any other way. (There's a risk of
pocket veto in any model, but we have checks and balances
to prevent that.)

    Brian

On 2008-06-06 06:38, Bob Braden wrote:

>  
>   *>
>   *> 2. Also re the Independent Stream: "...no changes to the Editorial
>   *> Board are being proposed." Let's discuss that. I don't like the
>   *> current degree of secrecy around the way the EB reviews independent
>   *> submissions.
>
> Brian,
>
> RFC 4846 (July 2007, Klensin & tHaler) established the rules for
> handling reviews of independent submissions.  In general, the RFC
> Editor has been attempting to follow that document since it was
> published.
>
> Originally, the RFC Editor used the academic model, in which reviews
> are (of course) shared with the author but not made public.  RFC 4846
> generally favors posting of reviews, although in fact it does not
> absolutely require it; see section 7.1.  In any case, the RFC Editor
> intends to follow the general thrust of 4846 by posting reviews on our
> web site, and we began the process of making that happen.
> Unfortunately, higher priority issues intervened, and we never got back
> to complete the task.  Thanks for your comment, and we will try to
> remove the veil of "secrecy" ASAP.
>
> Bob Braden
>
>
>      Especially if we end up spending IASA money explicitly
>   *> for this stream, I'd like to see all EB reviews being made public.
>   *> People who want to publish via confidential peer review have lots
>   *> of other places to try.
>
>

_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Paul Hoffman-2]

The proposed RFC Editor structure looks fine. It's good to see the
IAB getting this straightened out so that future bidders on the RFC
Editor contracts can know what they are bidding on.

As many people know, Standcore (basically, John Levine and I) bid on
the RFC Editor RFP last year, so we have thought a great deal about
what kind of structure would make sense. We think the proposed
four-part model makes sense. A few notes on the specifics:

- Of the two proposals for selecting the RFC Editor role (RFP from
the IAOC, selected by the community), having the RFC Editor being
chosen by an RFP from the IAOC is probably best. It seems likely that
bidders would want to bid on the RFC Editor and Production House
tasks at the same time, and it would make sense to let the IAOC bid
the two of them simultaneously.

- The person in the ISS role preferably should *not* work in the same
organization as the RFC Production House role. Having the Independent
Stream queue being input to the same organization that is supposed be
managing the queue can lead to errors and misunderstandings. All four
queues should be on the same footing.

- The RFC Publisher is truly a minor amount of work. If it is not
just given to the Secretariat, it should probably be part of the RFC
Production House job and let as a variable price contract. It is hard
to see how this would cost more than $3000/year, and could easily be
less than that, meaning that it is less than 1% of the RFC Editor
budget.

- The structure document did not lay out who would be responsible for
creating the new tools that many people have asked for, that would
make the process faster and more understandable. These include modern
tracking of author reviews, an updated xml2rfc system, better search
facilities, and integration of the RFC Editor queue and the I-D
Tracker. These tools could be developed by the RFC Production House
or the RFC Editor, but should be done with oversight of the IAOC and
with a specific budget for the tools.

Again, we feel that the structure proposed is a good one, and we look
forward to helping with the evolution of this important task.

--Paul Hoffman

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Brian E Carpenter-2]

Paul,

On 2008-06-23 02:49, Paul Hoffman wrote:
...
> - Of the two proposals for selecting the RFC Editor role (RFP from
> the IAOC, selected by the community), having the RFC Editor being
> chosen by an RFP from the IAOC is probably best. It seems likely that
> bidders would want to bid on the RFC Editor and Production House
> tasks at the same time, and it would make sense to let the IAOC bid
> the two of them simultaneously.

What do you see as the advantage in separating these two functions
into two bids? Wouldn't it be very clumsy for them to be executed
separately?

    Brian
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Paul Hoffman-2]

At 8:53 AM +1200 6/23/08, Brian E Carpenter wrote:

>Paul,
>
>On 2008-06-23 02:49, Paul Hoffman wrote:
>...
>>  - Of the two proposals for selecting the RFC Editor role (RFP from
>>  the IAOC, selected by the community), having the RFC Editor being
>>  chosen by an RFP from the IAOC is probably best. It seems likely that
>>  bidders would want to bid on the RFC Editor and Production House
>>  tasks at the same time, and it would make sense to let the IAOC bid
>>  the two of them simultaneously.
>
>What do you see as the advantage in separating these two functions
>into two bids? Wouldn't it be very clumsy for them to be executed
>separately?

Actually, we don't see any advantage in separating them; my apologies
if I made it sound like we did. We assumed that if the IAB wanted the
two roles separated, they had a good reason to do so. We don't think
it would necessarily be "clumsy" to have two different people in the
roles, but it would add overhead that isn't necessary. If both roles
are done by the same person, that's fine too.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Olaf Kolkman]

[Dropping the independent list in order to keep the discussion constrained to one place]

What follows are some clarifications and answers to issues brought up during the discussion. 

On Jun 4, 2008, at 3:59 PM, Frank Ellermann wrote:

Olaf Kolkman wrote:

The proposed model is posted on the RFC interest list, see

http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html

and made available through

http://www.iab.org/documents/resources/RFC-Editor-Model.html

Thanks for info.  Some quick observations while looking at the

picture of your model:  You don't cover the rather convoluted

interactions between IESG and "ISS", to fix that please sort

the "stream" columns like that:  IAB | IETF | community | IRTF.

Yes, the picture does take a high level view of the processes and production process.

But to clarify:
The convoluted interactions are documented in RFC4846, with cross reference to 3932, and thus well defined part of the existing review process. Nothing here that is going to change that. It is the ISS that in this model is responsible for following the process. Once the ISS is done a document with appropriate boilerplates pops out and the RFC production house takes over.

Frank also asked:

What does "selected by the community and confirmed by the IAB"

actually mean, is it the same idea as for area directors, i.e.

NomCom representing a random set of volunteers from visitors of

three out of five recent IETF meetings ?

That is one of the approaches, in the document we suggested an approach similar to that of RFC4333. There may be other approaches to selection of the ISS and the RFC Editor, and those selection processes may be different. Ideas, suggestions, and opinions are most welcome

Frank again:

Why should there be two persons - new "ISS" and new RFC-editor -

instead of one ?  In what way would a new "ISS" selected by the

NomCom be really independent from IETF / IESG considerations,

which is the whole point of this "independent" escape hatch as

noted two years ago in the RFC 4844 discussions by John Klensin ?

The _intention_ is to recognize the independence of the stream and construct an appointment process that matches that. This intention is (attempted to be) captured in the profile of the ISS "Good standing in the technical community in and beyond the IETF".

The reason why there are two _functions_ in the model is because they are different in nature and responsibilities. The ISS being an experienced technical person that understands the content and organizes and manages the process for getting that content reviewed and takes responsibility for approval. The RFC Editor being with a focus on style, presentation, and series continuity.  It seemed natural to decouple to function description. But it is not said that the same person, or organization cannot fill both of these functions. In fact, observe that Brian Carpenter suggested coupling between the Editor and the Production function.

Frank continued:

RFC number assignment should be the privilege of the RFC editor,

not of some "outsourced" RFC production entity.  This used to be

great magic in the past, and it is a completely subjective magic.

In an earlier version the RFC assignment lived with the editor. It was thought to be more pragmatic to move the magic to the production house, this seemed to be more in line with the current practice, as Bob Braden also argued in his June 4 reply.

And finally Frank remarked:

Moving some "RFC publisher" functions to the IETF secretariat

could make sense, if that is about maintaining a high traffic

Web server with tricky forms.  But the quality of some IETF Web

server forms is not yet up to the standard of some RFC editor

forms.  Working Web forms can't be expensive, please don't try

to fix it if it is not broken.

That is to some extend an implementation issue that should be decoupled from the long term perspective that we are trying to make with documenting this model.

Brian also had a number of queries:

1. What's the funding model for the "Independent Stream Supervisor"?
That's not a job title that is very inspiring, and if it's a volunteer
position, it would seem very unlikely to me that we'll find reliable
and conscientious individuals willing to do it in the long term.
I don't see it as comparable to an unpaid Editorship of an academic
journal, for example, unless it is described in much more exciting
language. But it also seems hard to justify as a funded service
on its own. "Expenses to support the administrative operation of
the Independent Stream Supervisor selected in this manner would
be part of the IASA budget." Well, that is a very explicit extension
of the scope of IASA beyond IETF activities. I'd want to see a
consensus call on that.

Currently the funding is provided through the RFC-Editor contract that is in place with ISI, so de-facto this is already covered by the IASA budget. In fact all functions in the model are currently executed and funded by IASA. 

Calling out the ISS as a separate function allows us to think about separate funding sources, although that also opens the question about the selection process.

Brian also remarked:

2. Also re the Independent Stream: "...no changes to the Editorial
Board are being proposed." Let's discuss that. I don't like the
current degree of secrecy around the way the EB reviews independent
submissions. Especially if we end up spending IASA money explicitly
for this stream, I'd like to see all EB reviews being made public.
People who want to publish via confidential peer review have lots
of other places to try.

Although maybe not completely orthogonal I think it would be good to have that discussion separate from this particular discussion. We converged on the independent approval process about 1-2 years ago and that cumulated in RFC 4846. What is important though is to assess if this model would prevent any changes to the approval process. I do not think it does.

Finally I observe that we have had no concrete feedback on the selection process by which the ISS and the RFC Editor should be selected. Would folk consent with a RFC 4333 type selection of those roles?

--Olaf

_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

[Paul Hoffman-2]

At 4:21 PM +0200 6/24/08, Olaf Kolkman wrote:
>Finally I observe that we have had no concrete feedback on the
>selection process by which the ISS and the RFC Editor should be
>selected. Would folk consent with a RFC 4333 type selection of those
>roles?

A RFC 4333-style selection process is probably OK for the ISS role
(review independent submissions) and the RFC Editor role (RFC series
continuity, style manual, and errata processing). However, from
earlier parts of this discussion, it sounds like both roles are meant
to be paid positions. If so, using RFC 4333-style selection to select
the people to fill the roles might be a bit odd, since RFC 4333 was
designed to select volunteers.

The compensation for each role would need to be stated up front
without negotiating with the chosen candidate; otherwise, the people
putting their names up for consideration won't know whether or not
they would want to accept if chosen. While predicting the number of
hours it might take to perform the ISS role based on history is
possible, doing so for the new RFC Editor role is probably impossible
due to lack of data. (As an aside, it would be nice if ISS were
compensated by ISOC instead of IASA to make the independence clearer.)

One possibility is that the IAB and IASA agree ahead of time what the
compensation for the ISS role would be, then do an RFC 4333-style
selection process, while having the RFC Editor role chosen by an
IASA-led bidding process like it was a few years ago.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
rfc-interest mailing list
rfc-interest@...
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest