All, As a participant in the newtrk working group and someone who actually ran one of the only reasonably successful experiments in that group, I think the community is owed a better accounting of why WG failed, and that steps should be taken to see that such efforts do not fail in the future. The newtrk working group was chartered to revise the standards track, with an understanding that the current one is demonstrably not working as it should. As I've previously mentioned, few if any specifications get to draft or full standard, and no review of PS had ever been done along the timelines specified in RFC 2026. Numerous proposals were made within the working group. The ISD proposal seemed to be the one that had the most support. However, this proposal ran into stiff opposition within the IESG and was effectively killed. We can argue until the cows come home as to whether or not the ISD proposal was ready for prime time. However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. Quite frankly we don't have the resources to have that happen. I suspect anyone who had any involvement with that group will be extremely reticent to work on process proposals in the future, because they will assume that any given IESG is likely to reject any output. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Is a working group the appropriate place to make process changes? I am leaning heavily toward "no" on that last one. Should the IESG simply both propose and dispose? Perhaps the IAB has a role of proposing changes. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf