Re: I-D Action: draft-hardie-iaoc-iab-update-00.txt

Dave Crocker <dhc@dcrocker.net> Thu, 04 February 2016 14:18 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4211B300E for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 06:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBnm-mBBE9H6 for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 06:18:08 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B361B300D for <ietf@ietf.org>; Thu, 4 Feb 2016 06:18:08 -0800 (PST)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u14EI6Z4013236 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2016 06:18:06 -0800
Subject: Re: I-D Action: draft-hardie-iaoc-iab-update-00.txt
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ietf@ietf.org
References: <20160202182036.26498.27650.idtracker@ietfa.amsl.com> <56B10131.7040603@gmail.com> <2DBB9F0D-0965-4562-9D9D-8183A0010071@gmail.com> <20160203223346.GQ27830@mx2.yitter.info> <56B292E2.4060702@dcrocker.net> <20160204013901.GS27830@mx2.yitter.info>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <56B35D9D.9030904@dcrocker.net>
Date: Thu, 04 Feb 2016 06:18:05 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160204013901.GS27830@mx2.yitter.info>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 04 Feb 2016 06:18:07 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/bwYYqcAvy88ZuYf66nWrewW497Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 14:18:11 -0000

Andrew,

On 2/3/2016 5:39 PM, Andrew Sullivan wrote:
> You seem to have elided the very part of my message where I said,

I assume folk have the original.  Quoted text is for setting context to 
the response.


>> Worse, the proposal seems to think that an IAB committee doing review is
>> somehow equivalent to one, continuing, deeply knowledge person actually
>> /participating/ in the IAOC's decision-making.
>
> … one, continuing, deeply knowledgeable person.  If it's important to
> you to distinguish between "following" and "participating" here, I'm
> happy to grant it.  But none of that gets to the problem that is
> really bothering me, which is …

The problem I cited was that the the need for a continuing participant, 
with appropriate context from outside the IAOC and from within, is key 
to the basis for the current ex-officio model.  Any effort to change the 
model needs to explain the ability to satisfy the functional goals of 
the position.

Also, the current draft is attempting to change a defined position for 
the IAOC/Trust but casts itself, instead, as making an IAB change.  You 
need to cast a proposal in terms of the IAOC and the IETF Trust, not in 
terms of the IAB.

And to establish a linkage to a separate sub-thread:  I think it would 
be quite a good thing to start with a discussion of 
deficiencies/limityations of IAOC and IETF Trust operations and views of 
how to improve its operation.  No, this needn't be comprehensive, 
attempting to boil the IAOC/Trust ocean.  The essence of the current 
proposal is an concern about staffing the IAOC/Trust.  That's a 
perfectly reasonable point of focus, to narrow the discussion.


> … this.  I don't think it is healthy, for the IAB or for the
> community, that we act as though the way to make this all work well is
> to have some _one_ who has all the state.  I think in the case of the
> IAB we should distribute the state more widely.

Distribution of knowledge and responsibility.  At the level of 
granularity you and the draft have offered, the usual result for such an 
approach is an operation with poor context and little accountability. 
It makes up for this by also being slow and frustrating for everyone 
involved.


>  I think it makes for
> a more effective and useful body.

Please provide examples for an operations-related efforts like this that 
demonstrate this result.  (And to anticipate the possible retort that I 
need to do the same for my assertion I'll offer that you folks are 
proposing the change, so you folk need to substantiate its operational 
superiority.)


   It also is a practical effect of
> taking seriously our usual claims that we work by consensus, that we
> reject kings and presidents, and so on.

So, rather than having one level of diverse-participation committee 
decision-making (the IAOC or the IETF Trust), you are proposing that we 
have two levels, namely the existing one plus the IAB program.  And you 
think that will produce improved results.  Why not just make all IETF 
decision-making be consensus-based by the IETF itself?  I offer that, 
not a strawman, reductio ad absurdum extreme, but as the natural 
conclusion to the justification you've just given.


>      • If the _ex officio_ people are expected to be participating as
>        enthusiastically as they are at present (I would like to think
>        that I'm holding up my end of the log in the IAOC and Trust, but
>        my colleagues there should feel free to correct me), then all we
>        get are more committee members.

You've forced things into two choices, when there actually are more.


>  The main problem is that we think there should be one
> person in the middle of all these different things.  It has struck me
> more than once that if someone brought us a system with a giant single
> state-exchange mechanism in the middle, many of us would immediately
> say, "Won't scale, and too brittle and vulnerable."  Yet we seem to
> think it a good feature in the organization.  I'm arguing that we can
> try another way.

The error in that analysis is that the IAOC/Trust is (are?) already an 
entity composed of a diverse sampling from the community that provides 
representation.  Adding another layer with more of the same doesn't 
obviously provide benefit and does obviously add to complexity and delay.



Suggestion:  A number of people have separately offered some very basic 
concerns about the proposal.  These concerns are not fixed with just 
better writing of the draft.  They call for re-thinking the issues and 
re-casting a proposal in terms of those issues.

Again, I think that it would be consonant among those separately-offered 
concerns to cast the proposal in terms of the IAOC/Trust, rather than in 
terms of the IAB.


d/