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

Leslie Daigle leslie at thinkingcat.com
Tue Nov 23 13:47:01 PST 2010

I'd like to say "thanks" to both of you for the thoughtful and 
clarifying exchange.

I, at least, found it useful in terms of elaborating where the specific 
concerns are, from both perspectives.


Ted Hardie wrote:
> On Thu, Nov 18, 2010 at 8:51 PM, Brian E Carpenter
> <brian.e.carpenter at gmail.com> wrote:
>> Hi Ted,
>> 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.
> I strongly agree on the consistency point.  But I think the RSE as
> described in any of these formulations has no power to affect
> the quality of work coming out of any the streams.  Assigning
> responsibility for it when we should not assign power to affect
> it strikes me as bad.
> <major snip>
>> 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.
> I don't think it has stepped outside its charter--RFC 2850 clearly
> puts the RFC series within the IAB set of responsibilities in section 2.3:
>    "The IAB must approve the appointment of an organization to
>    act as RFC Editor and the general policy followed by the RFC Editor."
> (and yes, I know you were the editor of that doc)
> I agree that the process that went from appointing an organization
> to splitting the responsibilities and appointing multiple organizations
> and individuals changed the amount of work for the IAB, but I
> still see them as the stuckee for the job.
>> 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."
> There is a big difference in my mind between being a source
> of policy that is responsive to the community and fostering consensus
> in that community.  At the heart of that is a much bigger conversation
> about the consent of the governed that we need to get into someday,
> but probably should be shelved for at least a little while.
> Thanks very much for your quick and responsive comments,
> regards,
> Ted
>>   Brian
>>> 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
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest


      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com

More information about the rfc-interest mailing list