Charters, "normal process" versus ISOC, etc. (was: Re

Dave Crocker dhc at dcrocker.net
Mon May 19 17:06:06 CEST 2003


hardie,

hqc> below, I think the attention the matter is receiving from the community as a
hqc> whole makes who nominally oversees the group less a matter of concern than
hqc> it might otherwise be.

I'd prefer to view it as desirable to have the criteria, for selecting
the AD who will oversee strategic changes to the IETF organization, as
being at least as stringent as we apply for other AD's.


hqc> I would personally focus the issue on how to get and
hqc> keep good chairs in these roles rather than focus on the appeals process or
hqc> reporting chain.

Indeed, the chair role has the most difficult, daily challenges for
these activities.


>>...that this particular AD was expected to
>>take "no objection" positions on any technical documents ...
>>  One couldn't
>>prevent such an AD from reading all the documents and taking 
>>positions,
hqc> Less-than-full membership seems to have a whole raft of other potential
hqc> problems which we cannot predict, so I'm not sure why this doesn't
hqc> fall under the same objections you cite below.

Because it really is at the choice of the new AD.  The question is what
is expected of them, not what they are "prohibited" from doing.


hqc> Pragmatism would then seem to argue against having a new AD for this
hqc> area having less
hqc> than complete responsibilities and rights,

There was no suggestion that their "rights" be limited, only the
expectations on their use of those rights. So, yes, lessened
responsibilities. But let's note that ADs have varied quite a bit, over
the years, concerning just how much effort they put in and how broadly
they range over IESG activities in other areas.


hqc>   Pragmatism would also seem
hqc> to suggest against creating a new AD slot for it, on the theory that
hqc> the IETF has
hqc> never before had an AD with a specifically non-technical remit

I was AD for the Standards Process, followed by Lyman Chapin holding
that position. The slot was very specifically about IETF process and not
about IETF technical work.

And we had an AD for User Services. It was an important area and
sometimes had a technical component to it, but I believe it mostly did
not.

(However indelicate, I have to express a meta-concern: We have been
experiencing a recent community trend towards people making firm
assertions about IETF history that are at variance with its actual
history. I'm sure the utterances are offered as honest assessments, but
I wonder what we can do to improve their accuracy?)


hqc> I would argue that we can say: "We will choose N folks from among a
hqc> volunteer pool
hqc> by verifiably random means to confirm that those chairing Working 
hqc> group A and Working Group B

1. Whatever the procedure is, you are inventing a new procedure.
Inventing new procedures involves substantial risk. I believe that was
John's point. It certainly is mine. It can't be a good idea to add that
unknown to this mix. (My lobbying for ISOC was based on essentially
replicating the ISOC role for Nomcom.) John K's proposal involves even
less cleverness than I was pursuing, in the sense that it invokes
completely detailed and well-understood procedures about which there
should be no questions. The appeal of that should be overwhelming to
folks.  Less cleverness is more better.

2. I am not sure I followed the nature and details of the "verifiably
random" procedure you have in mind, but the IETF has a very consistent
track record with use of statistics-based procedures in its analytic and
procedure work. The track record makes very clear that we should keep
the heck out of statistics and social processes. We wind up focussing on
the math rather than the methodological validity of the procedure. I'm
glad to discuss our lack of methodology skills at a bar bof.


d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>



More information about the Problem-statement mailing list