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

[hardie at qualcomm.com]

At 4:06 PM -0700 5/19/03, Dave Crocker wrote:
>
>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.

John has also commented on this, but just to make it clear, I understood
his original remark indicating an "expectation" that they would register
"no objection" as tantamount to saying "this isn't your business".  He
has since corrected my misunderstanding, and I agree that this is 
different from having
less-than-full membership.
>
>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.

Thanks for this correction.  I had thought that this was always held
in tandem with a technical remit, but I see from:
http://www.ietf.org/iesg_mem.html that both you and Lyman held it
at times when you were not also managing technical areas.



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

My experience of it (and I did some work in it both with Joyce and
April) was that it was technical, often in complex ways.  In many
ways a document like RFC 2635 is a harder to get right than
a MIB.

On the larger question of how to get history right, hopefully we will be
able to count on our longer term members to correct us when these
things are misquoted for a good while.  I'm not sure what to suggest
for making sure the misunderstandings don't arise.

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


"Everything should be made as simple as possible, but not simpler."
(attributed to Albert Einstein).

I grant the premise, but I am not sure that selecting a new AD
for a short-term process IESG role follows from it.  Making the
working groups normal groups under General seems to be simpler;
the reason not to do that seem like it might be distrust that the
sitting IESG or IETF chair would follow community wishes
in regards to the working group outcome.  That implied
to me that some oversight role derived from our existing
procedures was warranted.  Using the NomCom as a model
for that was simply because the NomCom process is
community-driven and not selected by any of the sitting bodies.
It is, granted, different from the usual role of the NomCom,
and it would require specification.  Whether that is needed
or not seems to me to rest more on whether re-using the
existing processes will or will not garner trust in the
outcome having been fair enough and open to satisfy
the current need.

As I said in my conclusion to the previous message, if that trust
is not at issue, then I'm happy to move on.

>2. I am not sure I followed the nature and details of the "verifiably
>random" procedure you have in mind,

I was referring to RFC2777 ,"Publicly Verifiable Nomcom Random Selection";
sorry if the atypical shortening was confusing.

				regards,
					Ted Hardie