Date: Mon, 10 May 2010 12:05:07 -0400
From: Donald Eastlake <d3e3e3@xxxxxxxxx>
Message-ID: <AANLkTilq58AENQmvCYwbSo197i2Auq_jC3j3IB_b0osQ@xxxxxxxxxxxxxx>
Mostly (these days) I prefer to make one comment, then keep quiet, but
this message from Donald needs a response...
| So, with such disagreements, someone has to settle it even if there
| isn't a clear consensus.
Yes.
| Pretty much all the bodies who could possibly
| make this decision have an extremely remote but theoretically real
| conflict.
If there is no consensus there is no change - no question it is the IESG
that gets to decide if a consensus exists (currently, that looks to me to
be a clear "no") but it shouldn't be the IESG that's creating the statement
upon which consensus is called (even if it weren't for the issue in question
here, that's another conflict of interest.)
But this ...
| I have confidence that if there is a clear consensus that
| day membership should count as attendance towards NOMCOM
| qualification, the IESG will see that. But I sure don't see such a
| consensus against the IESG suggestion so I think it is not only
| correct but that it should stick.
is 100% totally backwards. And why I am commenting on this issue a
second time - as this kind of thinking seems to me to have become far
to common in the IETF (I've seen signs of this in quite a few working
groups as well.).
If there is no consensus on a new proposal, the new proposal fails.
Here the IESG's suggestion is the new proposal, if there is no consensus
to adopt it, then it fails, and we remain with the rules we have now.
That rule merely requires "attendance" without saying how much attendance,
one day, two days, or more, all count as attending by any logical
interpretation of the words, so anyone who has attended 3 out of the
relevant 5 IETF meetings qualifies for nomcom - unless there is community
(rough) consensus to change that rule.
I agree with you that there is (currently) no consensus here, some people
like the IESG proposal, others don't - that's "no consensus", hence "no
change" - but "no change" means RFC3777 remains as written, not the IESG
suggestion fails to be defeated.
The IETF community as a whole needs to be watchful for (and reject) this
kind of thinking everywhere - another place I have see it is where a
"design team" (or just draft author) writes some text, and the WG discusses
some part of that, then eventually the WG chair (assumed correctly here)
decides that there's no consensus on some issue - unfortunately, often
that's been interpreted as "no consensus to change the design team proposal"
which is flat out wrong - if there's no consensus the existing state of the
world remains - which means (in this postulated example) the design team
proposal fails (on at least that one point), not that it remains as written.
That is, we must stop asking "do we have consensus to change this proposal"
and instead ask "do we have consensus to accept this proposal", the latter
certainly makes it harder to get things done, but the former is far to easily
open to abuse.
And then, since I am here anyway ...
Russ Housley <housley@xxxxxxxxxxxx> said:
| However, your suggestion is not practical. If there was a WG that could
| weigh in on this topic, then that would have been done, but there is not an
| existing WG with the charter to consider this issue.
Agree with all of that, except "not practical". See below.
| RFC 3777 was drafted by a WG, Last Called, and then approved by the IESG.
Yes - that is, the IESG determined that there was community consensus to
support 3777, that's fine.
| That is the process that made RFC 3777 a BCP. With the IAOC conducting the
| Day Pass experiment, an interpretation of the rule in RFC 3777 regarding
| NomCom eligibility is needed.
Why?
What is the problem supposed to be?
The Last Call certainly gives no clue, all it says is ...
The IAOC is conducting a day pass
experiment, making it necessary to augment the NomCom eligibility rules
to address IETF participants that make use of a day pass.
which makes no sense to me. 3777 doesn't say anything about "fully paid
attendance" or "attended for 5 days" or anything else, all it says is
"attended" - there is no obvious need to change it because of the day pass
experiment that I can see.
It has never been true that everyone who paid to attend an IETF meeting
(in the time before "day passes") attended all N days of the meeting, and
I cannot believe that either the authors of 3777, nor the community at
large, ever thought that they did. It has always been that some people
only attended a very short part of the meeting - yet 3777 was content to
just say "attended" without attempting to require any accounting of
attendance records (beyond merely having attended). I don't see that
reducing the financial burden upon some of those (short term) attendees
changes anything of significance, does it?
Certainly it is possible that the community might believe that the
current eligibility rules need tweaking - the current rules have been
in place 6 years now, which was about how long the previous set, with
the 2 of 3 meeting requirement, operated - so perhaps we're due for an
overhaul.
But that's certainly not urgent, there's plenty of time to form a new
working group, and have it thoroughly discuss the nomcom eligibility
rules - including (if that WG decides it is appropriate) whether we need
to determine just how much attendance counts as attending for nomcom
eligibility purposes. That is, there is no immediate need for a solution
for the coming nomcom that I can see, nor even for the following one
unless the chair of the next nomcom determines that there was in fact a
real problem and that clarification is urgently needed. Personally I
find it hard to imagine that happening.
I would certainly be astounded if in the dozen (or whatever it is) nomcoms
that have existed since the 2 of 3 rule was first introduced, that in
every single case, everyone on the list of volunteers had attended all
4 (or 5) days of the (originally 2, now 3) required meetings. I'd
be not at all amazed if sometimes some of the volunteers may have attended
just one day (for all kinds of reasons, such as the one Ed Lewis just posted
about) of one (or more) of the required meetings.
But I see no evidence that there has been some great difficulty caused by
that. Which nomcom chair's report raised this issue?
So, please enlighten us all - exactly why is some kind of urgent repair
needed? Why can't we continue using the current rules, where all is
required is unquantified attendance, at least until a WG, and then the
IETF as a whole, decides that some better criteria should replace that?
What actual problem exists to solve here?
| This point was raised at the last plenary, and
| the whole community heard many opinions about the right way to proceed.
I wasn't there ... did any of those opinions actually point to an actual
problem or was it just more of what has been seen here in response to this
last call, where he just have theoretical guesses as to what might be better
with no real evaluation of a range of different possible fixes?
Who initially raised this issue? Did it come from someone in the (existing)
nomcom process? Or from the IESG or one of its members? Or just from the
floor? If we knew where the first suggestion that something might need
changing originated, we could perhaps ask just why that conclusion was
reached, causing the issue to be raised.
| Given that discussion as input, an interpretation was drafted in the form of
| an IESG statement.
If there is some real problem that must be solved, such that a quick
solution really is needed, then first I'd expect to have seen some
statement of the problem, and a request for suggestions for fixes.
Do recall that IETF work is supposed to happen on the lists, not at the
meetings - so the discussion at the plenary might have been useful for
clarifying the issue, but cannot itself be the solution - whatever was
said there.
Then I would expect that some independent person (maybe a past poised or
poisson chair, or someone who might chair a new WG if one is eventually formed)
be asked to collect and consolidate the community ideas (in response to
the problem statement) and propose a solution (that is, assuming that this
doesn't go directly to a new WG because there is some justification for an
urgent fix).
Once that proposal was clarified, whether it be as an I-D, or just as
an e-mail message, the IESG could issue a last call on it - an I-D would
be best, as if approved, it could (fairly quickly) become an RFC that
would update 3777, and the process would be clear and documented properly.
Doing it this way means that we both avoid the IESG appearing to be
making changes to the process by which they are reappointed, and then
the IESG determining whether the community agree (roughly) with the
IESG's own statement - both of which are clear conflicts of interest,
just on the face of them (no suggestion of actual malfeasance, just the
appearance of the possibility that it could happen).
So...
| An Internet-Draft could have been generated, but the next
| steps would not have been different.
Maybe, maybe not - who can tell if perhaps someone independent from
the IESG might, after reading community suggestions, have come to
a different idea of what change (if any is needed at all) should be
proposed? How can we know whether the current proposal might not
have been motivated by some desire to boost fully paid attendance at
forthcoming meetings, rather than anything directly affecting the nomcom?
Your message suggests that you believe that the IESG proposal is the only
logical way forward, nothing would have changed (you suggest), and if
you have that frame of mind "something must be done, this is the only
possible solution that makes sense" then how can you possibly rationally
judge the community response?
This is exactly the kind of problem we have to avoid, and why IESG members
particularly must constantly be aware of potential conflicts.
This whole process seems to me to be flawed from the start, withdraw
the last call and start again (if there is really a problem that needs
a solution) and this time do it properly.
kre
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf