--On Friday, 22 September, 2006 16:33 -0400 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> wrote:
"Scott" == Scott Bradner <sob(_at_)harvard(_dot_)edu> writes:
Scott> It's not hard to see why the newtrk chair (me)
decided that Scott> newtrk had no real future unless we
happened to come up with Scott> something that the IESG
liked (without the IESG members Scott> providing much help
figuring out what they might like)
Scott, John, we can choose to be bitter and to look back at
past failures or we can choose to be constructive and look
forward.
If you believe Brian made the wrong consensus call, then say
so and get others to say so.
Otherwise, please get over newtrk and move on and find some
way of being constructive. I'm sure we could all tell all the
possible different sides of the newtrk story. Some would make
...
Sam,
While I appreciate your point of view, let me explain where I
stand on this set of issues.
First, I meant what I said in Montreal. I may continue,
reluctantly, to respond to issues of fact or interpretation as
to why we aren't moving forward on process issues, but I'm
through making new proposals for a while or stimulating such
proposals from others. I didn't initiate this particular
discussion but simply responded after yet another thread was
started about what happened in newtrk and what might be
necessary to get things moving again. I don't see any point at
all in recycling ideas that were proposed in newtrk as if they
were new and expecting them to get approval outside the newtrk
context and will probably continue to comment when such
proposals come up.
My Montreal recommendation was that, to the extent possible, we
just drop process discussions for a year or so to let the
community recover --from newtrk, from the IASA formation
process, from the noise level in IPR, and from other things.
I'm pragmatic about that: I think the mailing list changes and
IETF Trust language were critical and require attention now, but
I don't see work on less time-critical changes as being
productive. I believed the suggestion was constructive when I
made it and still do. I think there is lots of evidence that
the community doesn't feel strongly enough about the need for
major change to force such changes (e.g., in spite of IESG
resistance) and I am concerned about change proposals that are
discussed only among self-styled process experts because the
rest of the community has tuned out.
Consistent with that Montreal recommendation, my personal
preference and advice would be that we just lose the several
analyses and proposals for change (including Brian's two or
three documents) for a while, e.g., that the position of the
IETF Chair not be used at this particular time to stimulate
community involvement with individual I-Ds that would otherwise
probably vanish without comment. I see nothing significantly
wrong with Brian asking for that review; I just don't see the
broader IETF community as willing to do it in an effective way.
I would see it is problematic if Brian claimed community
consensus after getting a handful of comments from a homogeneous
subset of the community, but I see no reason to believe he
intends to do that.
I also believe that the community is sufficiently burned out on
process issues to call any apparent consensus on changes (or on
not making changes) into question and suggest that anyone who
wants to pursue those issues should cautiously watch the breadth
of participation in the discussions.
The combination leads me to the conclusion that Brian made
exactly the right call about newtrk, but that the "solution" to
newtrk's problems is neither a clone WG or a way to work around
the WG model in the area. On the question of whether there was
a reasonable prospect of newtrk making progress, the answer is
clearly "no"... regardless of whether the reasons for that
answer originate in the WG, in general community burnout on
process issues, or elsewhere. I would question whether Brian
exercised completely good judgment in unleashing a flurry of
individual process commentary and drafts while considering
whether to shut the WG down, but it is clear to me that, since
he remains a member of the community, nothing prevents him from
doing so if, as an individual, he considered it useful.
Once the Nomcom is formally established and starts issuing calls
for candidates, I do expect to write them a letter suggesting
that, in their investigations, they poll the community on the
importance of significant process changes. I will suggest that,
if they conclude that the community thinks such changes are
important, they consider willingness to shift approval of
changes away from the IESG as a litmus test for IESG membership.
I don't have any expectation that they will follow such advice
and I am not even completely convinced that it would be a good
idea, but I feel obligated to suggest it.
Finally, for whatever it is worth, while I can't speak for
Scott, I would not describe my reaction to the newtrk situation
as "bitter". I am saddened that an effort on the part of the
community to develop a set of proposals that fell within a WG
charter went nowhere. I am more saddened that the observed
patterns of behavior suggest that there is no point pursuing
other significant changes until after we have changed the
approval structure for such changes. My sadness is coupled
with, and reinforces, a concern that the IETF is getting itself
into a state in which significant evolution is impossible and
that, without such evolution, the IETF may find itself rushing
down the path to irrelevance or extinction.
I don't blame the IESG or its membership for that state of
affairs. A conservative approach of sticking to the job one
knows how to do rather than going off on adventures into the
unknown is arguably exactly the position the IESG should be
taking. But that is precisely why I now believe that those in
the community who want significant change --not mere
fine-tuning-- should be looking at the approval process rather
than at particular proposals that then would need IESG approval
under the current rules.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf