one detail is missing from the description off the NEWTRK event (I was the chair of the NEWTRK WG) I got an email before the message Brian points to from one of the IESG members that said (in so many words) 'the IESG wants you to stop doing this' about the Klensin proposal - nothing about community considerations - i.e a specific example of what John describes as the IESG substituting its judgement or preferences over any community considerations Scott > On Aug 20, 2024, at 9:16 AM, John C Klensin <john-ietf@xxxxxxx> wrote: > > Brian, > > A few comments inline below, with considerable agreement but perhaps > with a tad less optimism... > > --On Tuesday, August 20, 2024 17:20 +1200 Brian E Carpenter > <brian.e.carpenter@xxxxxxxxx> wrote: > >> John, >> >>> IIR, you were IETF Chair at the time of the NEWTRK debacle. If so, >>> insights from you about what went wrong there and how it might be >>> avoided in future broad-scope efforts would probably be very >>> helpful to the IESG and the broader community. >> >> (I've left the rest of John's message below in case anyone needs >> more context.) >> >> Yes, I was the very new IETF and IESG Chair when NEWTRK's output >> failed >> to get past the IESG. For background, I took over from Harald >> Alvestrand >> as Chair (and General Area AD) in March 2005, and the crucial >> discussion >> took place at the IESG retreat meeting in April 2005, where there >> was essentially no consensus (not even rough) for the ISD proposal. >> >> The result was this: >> https://mailarchive.ietf.org/arch/msg/newtrk/j8Si3b0cqnQSX5a5Ee8NIV >> dyZg4/ >> >> The work continued during 2005 >> (https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd >> /history/) >> but it remained the case that there was no enthusiasm for any such >> change in the IESG, nor even for reducing the number of stages in >> the standards track (that came later), or even for an attempt to >> clean up the existing process documents. > > It was also the case, at least IMO and IIR, that the authors, WG > leadership, and much of the WG were thoroughly demoralized by the > IESG's "lack of enthusiasm", including some questions about whether > the decision to kill the work without even an IETF Last Call was > proper under the procedures. Part of the problem is that the message > you cite above can be read in several ways. I don't think it is > useful to dissect it in detail now but one of the key interpretations > in the WG was that the IESG was looking for excuses to avoid even > further discussion that might change how the IETF worked and, e.g., > if there were questions about the scope of the WG and the problem to > be solved, those questions should have been addressed (and actually > were addressed) at WG charter time, not when documents were ready for > Last Call and publication. There was also a general sense that there > was no point trying to appeal the IESG's decision because it was > relatively clear that, under the circumstances you describe, such an > appeal would be viewed as an attack on an already overextended IESG > and would be very unlikely to result in any change (other than an > increase in hostility) regardless of what the IAB had to say. > > In retrospect, the way NEWTRK was handled may have marked a turning > point as the first time, at least the first significant time, when > the IESG because less of a consensus-determining body and substituted > its judgment or preferences for that of the community. > > I should stress that I have never seen you, or any other one or two > IESG members as the problem. The problem was what you describe as > "no enthusiasm" within the IESG for change or even processing > documents that might lead to change. > >> By the end of 2005 the NEWTRK WG was more or less non-functional, >> which I guess was due to the damper of the IESG response. > > Yes. See above. And I think that puts us more or less in agreement > so far. > >> After >> NEWTRK was formally closed, I made a couple of attempts to start >> non-WG efforts (baptised PESCI and PUFI) but they failed. >> >> Looking back on some of the related email in my personal archive, >> I think one of the main problems was that just keeping the >> existing process running, from I-D submission to RFC publication, >> was so fragile that many ADs were trying to avoid process change >> at all costs. > > Regardless of the reason, "avoid process change at all costs" was > what things looked like within the WG at the time. And that is > consistent with your "damper of the IESG response" comment above. > Since NEWTRK was chartered to be entirely about change, with the > presumption that the changes were likely to be significant, there was > even some feeling within the WG that the IESG should at least have > taken responsibility, announced that its charter was no long in line > with anything the IESG was likely to process, and shut it down rather > than providing that damper and waiting for it to fizzle out. > > >> At the time, remember, we didn't even have an IETF >> Administrative Director (IAD) (until June 2005), we didn't own >> our own intellectual property (until the end of 2005), the data >> tracker was minimal and supported by pro bono effort, and the >> stability of the RFC Editor process was in doubt. There is simply >> no comparison with the stability that sound financing and the >> advent of the LLC have brought us. >> >> One thing is clear to me, however. If we want to make a success >> of clarifying and improving the standards process, we need the >> IESG on board from the start. > > And _that_ was exactly the point of most of my cautionary comments > about a 2026 overhaul, the moderation discussions, and so on. Of > course, the NEWTRK WG, after a fairly uneventful charter approval > process and what the WG believed was a fairly clear charter, believed > that the IESG was on board from the start there too instead. At some > point, a point at which the WG was quite surprised and independent of > the specific reasons, that gave way to "avoid process change at all > costs". I would therefore go a bit further and say that the IESG not > only needs to be on board from the start, but needs to be actively > watching the WG's efforts and actively providing feedback so that, if > the IESG becomes skeptical about the WG's efforts and directions, the > WG knows about it early rather than being surprised after publication > is requested. That is especially important if the WG's efforts span > membership turnover in the IESG. > > I had not thought about it this way before, but that is probably > another difference between technical work in the IETF and work that > could result in significant process or organizational changes (not > just minor tweaks) > > >> *In April/May 2005 when the above email was composed, only two >> or three IESG members were on the NEWTRK list.* >> >> The ADs need to be part of the process, and hopefully part of >> the rough consensus, *before* any resulting documents get near to >> being ready for formal IESG review. So I've added a Cc. > > Again agreed, and see above. Unfortunately, that view appears to me > to be at variance with an IESG that, several times in recent years, > has taken the position that, once WG leadership is appointed and the > WG chartered and launched, there is no need for the IESG to pay much > attention to it until document publication is requested, at least > unless they get a request from the WG Chair or a formal appeal. > Given the (completely understandable) circumstances that seem to have > led to that view, it may be yet another reason to separate work > concerning IETF processes or operations from work that is more > technical. > > best, > john >
