Hasty procedural changes (was: Re: [RFC 3777 Update for Vacancies])

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Thapparently-strongly-held ursday, October 25, 2012 09:23
-0400 Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:

> Bob, Russ... repeating here what I said in the other thread, I
> suggest that...
> 
> - the authors of  draft-ietf-genarea-bcp10upd post an -01
> version TODAY, incorporating comments received so far,
> 
> - Russ, as Gen AD, immediately issue a formal (4 week) last
> call on that version, and
> 
> - the document be put on he 29 November IESG telechat for
> approval.
> 
> If we do that, unless something odd happens we will have this
> process update formally approved BY OUR PROCESS in five weeks.
> 
> Let's please not delay.

Barry,

I really, strongly, object to this way of proceeding.   Making
fundamental procedural changes in haste and in the middle of a
perceived crisis is never a good idea for any organization.  My
experience leads me to believe that IETF is even less good at it
than average, but, even if your experience differs, it still
isn't a good idea.  Doing it right now is particularly bad
because, despite the many postings on the list, a significant
fraction of the community is (and should be) focused on
preparation for the technical work of the IETF meeting or on
clearing up other work so that they can attend, not on
discussion of a procedural change that appeared in a late-posted
draft.   A four-week Last Call offers some protection against
that but maybe not enough (I note that the IESG has often
required longer-than-minimum Last Call periods when the Last
Call spans IETF meetings and/or major holidays).

In addition, making a procedural change to deal, effectively
retroactively, with a problem that is already in progress simply
has a bad, ex post facto, odor about it, an odor I believe we
should not ignore.

Let's deal with the matter at hand and the associated perceived
emergency and then, after the dust has settled, go back and
review procedures.  If you want a more pragmatic argument than
the "bad idea to rush through a procedure change" one above,
consider that your desired fast schedule could be entirely
derailed by _one_ member of the community waiting until the IESG
votes and then lodging an appeal whose substance is that, if the
IESG can change procedures in this way to change the rules as
applied to a particular situation, especially one related to a
personnel matter, that predated the change, it makes fairness
impossible.  

While I disagree with most of them, I've seen enough comments on
the list to the effect that, if recall is the only option we
have, we need to use it -- comments based on principles that are
apparently strongly-held by those making them-- to believe that
such an appeal is not entirely unplausible**.  (And my apologies
if I'm giving anyone ideas they didn't have already.)

So let's solve the present problem using good sense and the
tools at hand.  

>From my personal point of view, either of the following would be
rational, consistent with good sense, and just about as fast as
your proposal:

(i) If the IAOC is unanimously (obviously less Marshall)
convinced that everything plausibly possible has been done to
try to get a response from Marshall and that that there is no
reasonable possibility that he is unaware of the situation, then
a conclusion that he has resigned by his silence would seem to
be in order.  Personally, I'd like to see that in a resolution
in which the steps taken are reviewed, the unanimity is
recorded, and the resignation is noted.  I'd prefer to see that
resignation noted as "presumably for personal reasons" as well,
rather than "deeming the position vacant" because I would prefer
that we not hint at anger at Marshall in the record.  But, if
those distinctions are too subtle for the IAOC. so be it.

(ii) The IESG could use its implied authority to interpret RFC
2026 (an authority it has at least implicitly applied many times
in the past).  It could interpret the 2026 variance procedure as
applying to all bodies to which 2026 applies, whether they were
created earlier enough to be enumerated in 2026 or not.  (FWIW,
I personally believe that interpretation would be correct
relative to the intentions 16 years ago.)  That procedure could
then be used to treat the current situation as a resignation
without creating any unfortunate precedents.

While either of those approaches could be appealed as well, it
would be far harder to create a plausible claim of unfairness
in/to the community.  Indeed, it might be that only Marshall or
someone plausibly acting on his behalf, could reasonably appeal
and, if that were to occur, the real problem of non-response
would presumably disappear. 

I think other approaches are plausible too.  I hope we can avoid
the recall procedure, not because it would take a long time but
because it involves a level of condemnation of Marshall that I
believe that, in the light of past contributions, we should
bypass if possible.   Given the number of years we have gone
without ever exercising the recall procedure, I'd rather reserve
"first person ever recalled" for someone who has misbehaved in
some rather nasty way and I'm not convinced that Marshall
qualifies.  But even it would be better than trying to make a
significant and permanent procedural change on a "let's see if
we can do it before the end of November and then retroactively
apply it to this problem" basis.

best,
   john

** I've used "plausible", "rational", and their synonyms several
times in this note to stress the principle that the IETF should
continue to favor good sense and consensus over rigid rules and
their more rigid consideration.  If we cannot continue to do
that, I believe we are lost because our procedures are not
nearly good enough (or updated carefully enough every time
something changes) to sustain a rigid adherence to the letter of
the rules and nothing else.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]