Christian, > On Jun 25, 2019, at 9:15 AM, Christian Huitema <huitema@xxxxxxxxxxx> wrote: > > > On Jun 25, 2019, at 8:33 AM, Ted Hardie <ted.ietf@xxxxxxxxx> wrote: > >>> On Tue, Jun 25, 2019 at 8:01 AM Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: >> "The RSE is responsible for the performance of the RFC Production Center and Publisher" >> >> The task would look a lot different, honestly, if that part were separated out, and it may be that the community should consider a separation there. It is difficult to be certain, since the large number of other touch points with the current RPC's organization (AMS) may color our thinking, but making this more directly coupled to the LLC as a contracting authority or the stream managers might be a good structural change > > Yes. That's became pretty obvious to me after working just a few months with the RSOC. In the current structure the RSE is supposedly accountable for the RFC production center, yet has no way to actually manage it. Separating that clearly would remove a big source of stress. > > The other source of stress is the independent series. I do believe and so many times that this streams provides useful checks and balance against the IESG. It is clearly a source of tension, but that tension should be assumed and managed. This, so called “stress” is largely independent of the RSE. That’s why there is an Independent Series Editor (see RFC 6548). This is largely independent of the RSE. I don’t see the RSE’s involvement to be significant. The tension is between the ISE and the IESG. > > The question then is, what is left for the RSE. The RFC Editor report is all about the RPC work. What would it contain if the RSE did not formally manage the RPC? Would the bulk of the RSE work evaporate? I think not. > > The RSE could actually focus on the series evolution, and there is plenty to do there. For example, we are using a bespoke format in the name of accessibility and long term archival, but it requires specialized personnel and tools which more than double production costs compared to other organizations. > > We are also handling code snippets and abstract language specifications by including them in our specs. Do this code objects require the same management as specification texts? What about bug fixes? > > We inherited a structure in which RFC are immutable. This leads to the errata process and long cycles of updates by WG processes. Is that the best we can do? > > We hold the RFC series in great veneration, but we cannot answer simple questions like who reads it, what is their impact. How can we manage change without data about our results? > > I would like to see the RSE focus on such questions. And I think removing the RPC management and the ISE tension from the role would help that. These are all fine questions and ones which I too would like to see the RSE look at. This is the main part of the RSE's job, that is, the evolution of the RFC Series. It’s very unfortunate that the IAB choose a course of action that was taken by the current RSE as vote of no confidence. While we are talking about changes, we should also be talking about should the IAB continue in its current role with the RFC series. With this event, and things like the RFC++ BOF, I am wondering if the IAB should continue in its current role regarding the RFC Editor and Series. Bob
