[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt

Ted Hardie ted.ietf at gmail.com
Thu Nov 18 16:33:17 PST 2010


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.

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."


regards,

Ted


> 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.
>
> Regards
>   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
>> me).
>>
>> A
>>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


More information about the rfc-interest mailing list