Re: [Ianaplan] Process concern regarding the IETF proposal development process

Miles Fidelman <> Mon, 26 January 2015 13:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E9F91A88C0 for <>; Mon, 26 Jan 2015 05:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f-1gB6PSxQ4E for <>; Mon, 26 Jan 2015 05:43:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12C941A8A70 for <>; Mon, 26 Jan 2015 05:43:06 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 46575CC15B for <>; Mon, 26 Jan 2015 08:43:06 -0500 (EST)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 1gtd080pOT6s for <>; Mon, 26 Jan 2015 08:43:04 -0500 (EST)
Received: from new-host.home ( []) by (Postfix) with ESMTPSA id 53EADCC159 for <>; Mon, 26 Jan 2015 08:43:04 -0500 (EST)
Message-ID: <>
Date: Mon, 26 Jan 2015 08:43:03 -0500
From: Miles Fidelman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Ianaplan] Process concern regarding the IETF proposal development process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jan 2015 13:43:10 -0000

Andrew Sullivan wrote:
> On Sun, Jan 25, 2015 at 10:28:54PM -0500, Miles Fidelman wrote:
>> Well, on that later note, all I can say is that every time I get involved in
>> a proposal effort, lots of people review the terms and conditions section,
>> and provide input to council - we don't treat it as out-of-scope.
> Do I read you correctly as suggesting that the IAOC needs input on
> terms when it makes agreements?  If so, I think that is sort of right,
> and sort of not.

Well, yes.  I've yet to find a successful negotiation or contract 
execution where program management was not heavily involved in providing 
direction to the lawyers and contracts officers.

> The IAOC is not one person, of course, so to begin with we already
> have a group of people who are reviewing one another's work.  Those
> people are appointed in different ways, so that it's not even one
> point of view that arranges the appointment.
> Second, the IAOC works on instruction from the IETF.  If the IAOC came
> back with some agreement that was contrary to IETF consensus, there'd
> be a big to-do.  And the chair of the IETF sits on the IAOC _ex
> officio_, which means that the interests of IETF consensus are
> formally inside the room.

And this is the big issue that Richard (if I might speak for him), 
myself, and several others had withe the process - the WG was not 
representing the IETF "community" in that its charter explicitly 
excluded policy, legal, contractual, and governance issues from its 
scope.  So those issues were not addressed by open, transparent, 
consensus process.

> Third, the IAOC is exquisitely sensitive to these sorts of issues.  I
> seem to recall the IAOC asking specifically some questions around a
> knotty decision they had to make, involving some
> cost-vs.-participation trade-offs.  It doesn't happen often -- you
> really can't practically negotiate a contract with one party arriving
> with 1200 of their closest friends -- but I think the IAOC tries
> rather hard to strike the right balance (and when they mess up, boy do
> they hear about it).
> This is the way the IETF does it.  It's of course not perfect, and I
> can see ways in which, were one inclined to think that processes can
> be written to ensure nothing bad can happen, one would want to alter
> the approach we're using.  I happen not to believe in processes to
> that degree, and prefer an arrangement in which the community review
> of results (coupled with the logical possibility of recall) sends
> adequate feedback to a body of people who have in the past shown
> themselves to use sound judgement.

"This is the way <we> do it" is a pretty good way to get proposals 
thrown at without reading.  It's also been the cause of an awful lot of 
failed systems, or worse, major losses on contracts when customers 
insist on "this is what you promised to deliver."


Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra