John,
JCK> the outlines of this were
JCK> presented in plenary in Seoul and the general consensus was that
JCK> people should move ahead with this process,
1. Attendance by the on-going IETF pool of participants was _very_ poor.
Any attempt to claim that positive feedback at that event is somehow
representative of the larger community should raise some deeper
questions about IETF process. (And by the way, claiming that that room
showed strong support does not match my own perception or the perception
of quite a few other attendees.)
2. An "outline" is very different from a detailed specification and I
carefully stated that Harald's note appears to indicate that things have
moved beyond consideration and into actual implementations. If that is
not what is happening, then Harald should explain what actual is
happening.
3. Presentation and discussion at a face-to-face IETF meeting is never
an IETF decision, remember? What happened to the explicit confirmation
with the _real_ IETF plenary, namely the online community?
JCK> Nothing has appeared on
JCK> the IETF list, or in any other place that I'm following, that
JCK> would convince me that there is community consensus against
JCK> their proceeding, and draft-daigle-adminrest-00.txt has been
JCK> posted since February and hasn't seemed to draw much negative
JCK> attention either.
1. So this is one of those "proceed if there is no massive objection"
kinds of decisions? Shouldn't a fundamental change in IETF
administrative structure carry an expectation of rather more proactive,
broad-based support, rather than merely waiting for some sort of
opposition constituency to assert its ugly head?
2. Hopefully you are not suggesting that Leslie's document was a
specification. For that matter, at the plenary there were basic problems
raised with it and there has been no follow-up to those concerns.
JCK> We approve standards on far less
JCK> demonstration of consensus than that.
We do?
We approve actions where there is no history of developing a spec and,
for that matter, no public spec?
And when there has been effort to develop direct support?
Where do we do that, John?
CK> We have some, I think
JCK> considerable, evidence that a large fraction of the participants
JCK> in the IETF have concluded that, while they want these external
JCK> administrative processes to run smoothly, efficiently, and well,
JCK> they lack the interest and/or expertise to want to be deeply
JCK> involved in them.
So the choice is between being "deeply involved" or being entirely
excluded from any meaningful review of the details?
That is the pragmatic distinction you are suggesting.
For that matter, those who _are_ willing to be deeply involved do not
have access to the details. In fact during Leslie's plenary presentation
it appeared that the details did not exist. By contrast, Harald's
posting implies that they do exist now, yet have not been subject to any
public specification, review and approval.
JCK> Given that, what sort of public cheer do
JCK> think you is needed?
One that involves honest and open review and comment, of a detailed
specification, John. The same as is considered required for all other
IETF work.
JCK> Whether or not it is critical path is, IMO, a separate question.
That's why I asked it separately.
JCK> Even if one ignores the more general issues raised in RFC 3716
JCK> and draft-daigle-adminrest-00.txt (and without discussing their
JCK> relevancy or importance), we are in a situation in which we have
JCK> a shrinking resource base relative to costs.
There are a number of very different ways of dealing with our current
financial problems.
1. Holding 2 meetings outside the US in one year, with the serious
reduction in participation that comes with it, is NOT helpful towards
reducing the financial problems, nevermind that it serves to exclude
participation.
2. Constantly going to different cities is not a way to reduce costs,
since there is no learning curve and no ability to re-use any special
resources.
3. Signing venue contracts less than 6 months before the event is also
NOT a way to get expenses under control. It is typically better to sign 2
years in advance or thereabouts.
4. Going to expensive hotels that are isolated from less expensive ones
is also not a good way to ensure broad-based (and larger) participation.
Note the venue for the up-coming meeting.
5. I'll just bet there are other actions that can reduce costs, no
matter how resistant folks might be to them...
Bottom line:
We have not been managing our meetings in a way designed to
reduce costs and encourage attendance.
JCK> While a number of improvements
JCK> have been made, most of the costs arise from a fixed base, e.g.,
JCK> fewer meeting attendees may mean lowered cookie costs, but
JCK> doesn't lower the significant meeting costs, much less all of
JCK> the other secretariat costs.
We could, perhaps, also benefit from a more serious review of current
expenses, especially as soon as we start hearing the mantra of fixed
secretariat costs.
Reality check:
Are you suggesting that secretariat costs are going to go down?
I do not recall seeing any serious suggestion of this in the
entire array of public presentations and discussion, and I am
quite sure there is no serious analysis that proves it, unless it
has been developed privately in the last few months.
So, even if we ignore the minor fact that our administrative problems
are not what is threatening the existence of the IETF -- whereas our
inability to show timely, useful productivity is.
Even if we ignore that, we have moved from "we have an administrative
problem" to "we are implementing changes" with no explicit rationale, no
detailed description of those changes and no evaluation of their likely
efficacy.
JCK> In that environment, having
JCK> separate pools of funds, with no ability for the folks who the
JCK> IETF community holds responsible for keeping things going to
JCK> make priority decisions and move things around is, well, nuts.
Indeed, the current situation is nuts. It is nuts to focus problems that
are not threatening the relevance of the IETF rather than ones that are.
And it is nuts to proceed to implementation with no clear assessment of
the benefits to accrue.
The funding and administrative mixture of the IETF is indeed bizarre but
that does not automatically mean it is the thing to treat as an
emergency, especially since we are approaching 3 years of not treating
the real emergency as an emergency.
JCK> And those financial structure issues could bring us grinding to
JCK> a halt -- or increase meeting fees to the point that they would
JCK> become a significant barrier to participation for some people.
And I'll just bet you didn't intend that line to be humorous...
The various financial and procedural ways the IETF has been raising real
participation barriers are substantial. Nevermind that there is nothing
that has yet been presented to demonstrate that the actions to be taken
will reduce IETF attendance fees.
JCK> Of course, most of that is discussed in RFC 3716.
Actually, all that document does is to describe the existing, strange
set of administrative and financial structures. It does not propose
detaild solutions -- Section 4 is very broad strokes and tentative. It
does not evaluate choices. It does not evaluate existing operational
practises that could be improved. It does not evaluate this set of
issues in relation to decreasing IETF relevance.
It does not, in other words, do more than evaluate the current funding
and accountability relationships. So, 3716 is an entirely fine
document.
But let's not claim that it does more than it does.
JJCK> Last Called. Perhaps I've missed it, but I haven't seen an
JCK> outpouring of comments and complaints about its content.
Given the failure to address the concerns that _were_ raised at the
Plenary, John, there are multiple, possible explanations for the lack of
public comment.
d/
--
Dave Crocker <mailto:dcrocker@xxxxxxxxxxxxxxx>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf