[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt
Brian E Carpenter
brian.e.carpenter at gmail.com
Thu Nov 18 20:51:58 PST 2010
On 2010-11-19 13:33, Ted Hardie wrote:
> On Thu, Nov 18, 2010 at 11:59 AM, Brian E Carpenter
> <brian.e.carpenter at gmail.com> wrote:
> Hi Brian,
> On the "Broad" side, I think you are mixing arguments for the
> validity and importance of multiple streams with arguments for
> an RFC Series editor with executive authority. It's very
> hard to follow from your statements to "the RSE would be
> toothless if not given contract management rights over the
> publication house" (something you've previously mentioned
> as an issue with more narrow models). What you've written
> seems to me far, far more like "adult supervision
> over RFC series *content* is required", which has been repeatedly out
> of scope for this job.
I would s/content/quality and consistency of content/ in that last
sentence, not to mention the integrity and positioning of the series.
I have too much faith in the 2nd law of thermodynamics to believe
that four separate streams, however well they manage their own content,
will guarantee overall quality and consistency.
Maybe where we differ is that I don't see the IAB as being in the
least likely to proactively ensure those points (and indeed it is
not chartered to do so).
I have to say that when I joined the IESG in 2005, I didn't have
this view, and I was much close to some form of the narrow view.
But what I observed over the following two years did change my mind.
Each stream is focussed on its own needs; nobody except the Editor
is focussed on the big picture.
> On the "Narrow" side I can't fault you, since you started
> from the idea that you don't see how it makes sense, but I have to
> say that you did a fine job demonstrating that the output matches that input.
> On with a revision for your "Narrow" side.
> "2. Narrow:
> The Internet technical community produces documents within the RFC
> series using three different processes; each of those is separate, but taken
> together they form a one of the most important ongoing conversations on the
> development of protocols, processes, and other aspects of the Internet's
> evolution. In order to support their continuing to serve as a coherent
> combination, the IAB has been tasked with hiring an RFC Series editor, whose
> job it is to ensure the continuity of the overall series. This senior technical
> editor will be charged with ensuring that the series will be
> consistent in style, that it will be accessible both to current users
> and in archives, and that it will evolve as the ongoing conversation evolves.
> In addition to a strong background in technical publication, archival
> methods, search, and accessibility, the the RFC Series Editor should posses
> the ability to maintain professional relationships with a variety of technical
> communities, as she or he will be a critical point of communication
> among the producers of documents for each of the document streams
> within the RFC Series. As the series editor, the RSE will need to
> lead community discussion and foster consensus on a variety of topics
> related to the series growth and evolution. While the IAB will retain
> oversight over the overall RFC Series, the community expects that the
> RFC Series Editor will have expertise in publication beyond that of the typical
> IAB member. The individual hired must be able to use that expertise to
> demonstrate the value of both efforts to maintain continuity and to
> foster change."
Thanks for that. One factual quibble:
"the IAB has been tasked with hiring an RFC Series editor"
Actually didn't it task itself with that, after deciding how the
RFC Editor organization referred to in the IAB charter should
be organized? It doesn't really matter for present purposes,
but I increasingly believe that the IAB has stepped well outside
its charter in this matter.
That aside, when you say "the RSE will need to lead community
discussion and foster consensus...", this seems quite close to
some of what I wrote: "there needs to be a proactive source of
strategy and policy that is responsive to the wider community."
>> 2. Narrow:
>> The IETF, IRTF and IAB processes produce trustworthy documents
>> and there is no need for additional checks and balances.
>> The Independent stream has no particular value (various crypto
>> algorithms, proprietary protocols, and the material rejected
>> by IETF WGs and ADs, can be published elsewhere). All that is
>> needed is someone to publish a style manual and act as go-between
>> between the production house, the publisher, and the IAD when
>> there's a contract issue. When something goes serioulsy wrong,
>> the IAB will give up Internet architecture for a few months to
>> micro-manage the details.
>> Brian Carpenter
>>> On Wed, Nov 17, 2010 at 09:37:15PM -0800, Dave CROCKER wrote:
>>>> His mandate was to formulate recommendations, but now he's being told to
>>>> formulate a transcription of his thinking. Different task.
>>> Well, then, why in the world should we even bother commenting? We
>>> have recommendations. According to you, we're done, no? Why am I
>>> wasting my time on this?
>>>> That's the part that is strange. It is not as if any of us lack
>>>> experience within this community or especially with the RFC process.
>>>> Apparently a tutorial is needed about the RFC Editor, for those reviewing
>>>> the proposal?
>>> It's fun to put up straw people to knock them down, but where I went
>>> to school it was also a fallacy. I won't speak for others, but I'm
>>> not asking for a tutorial. I don't have intimate knowledge of the RFC
>>> Editor's job, and I can easily imagine that there are plenty of
>>> details that need to be in a job description (there are such details
>>> in the existing draft) but for which I don't have any context in which
>>> to make a judgement. If I make a recommendation about a course of
>>> action, it is just automatic that I would have a reason why. That's
>>> all I, personally, am asking for. And Glenn is in the happy position
>>> of having spent a year doing a job about which he is making a
>>> recommendation -- exactly the basis on which the recommendations were
>>> to be developed, as I understood things. But perhaps you're right and
>>> reasons are not needed. That'd be good, because it would free up the
>>> time I'm spending on this particular penance for my many sins, since
>>> there wouldn't be anything to review.
>>>> Does the proposal specify functions that are unfamiliar? Do you think
>>>> those functions do not need to be performed or that they should be
>>>> performed elsewhere?
>>> I think you will find that I sent a message to this list while we were
>>> still in Beijing which argued that that distinction is where the
>>> fundamental issue is. In that message, I suggested that _if_ we
>>> accept the broad construction, then the particular recommendations in
>>> the draft were (to me) more or less good enough.
>>> I still don't know what to think about the broad/narrow choice. I
>>> will tell you that finger-wagging, accusatory (not to say
>>> condescending) messages to the list make me feel like my initial
>>> impulse to put my head under the covers was the right one.
>>>> This is an on-going service. Problems arise, but the "problem" the RFC
>>>> Editor is to "solve" is production of RFCs, archiving them, and making
>>>> them available to the community. The other "problem" is looking for
>>>> opportunities and requirements for enhancements. What other sort of
>>>> problems are you thinking should be cited and solved?
>>> That is a useful additional way to think about the broad and narrow
>>> constructions. The second "problem" you list there is in fact part of
>>> what's up for debate: is the RSE a job that has that function? Does
>>> someone need to do it, and if so, is the RSE the right person? As I
>>> have previously suggested, the draft (or the summary, whatever it is
>>> we're supposed to be talking about) could be very much enhanced by
>>> saying _anything at all_ to justify the view that the RSE is in fact
>>> the right person for this. Leslie pointed out in this thread that the
>>> recommendation about opportunities and "outreach" in the draft as it
>>> stands is a potentially large sink of resources. I think it could
>>> take all the RSE's time. It strikes me that that part of the job
>>> could easily swallow the production-of-RFCs function, and that is at
>>> the very least worrisome.
>>> I hope this makes my perspective clear. I understand that there is to
>>> be a new draft in the future. I will read it. I don't expect to have
>>> much more to say about the topic until it comes out (although if Glenn
>>> wants clarification about anything I've said, he is welcome to contact
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
More information about the rfc-interest