Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: Internet-Draft draft-rsalz-2026bis-00.txt is now available.
From: Scott Bradner <sob@sobco.com>
In-Reply-To: <E51C0C7A3E6342A9B146569D@PSB>
Date: Tue, 20 Aug 2024 10:02:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <70BA7C4E-F2D7-4C04-81F7-2EDF23857BCF@sobco.com>
References: <9253BAA6-2278-496E-8832-EEB802B54242@sobco.com>
 <63c4e784-f949-4d5c-97c6-889d2d5bca3a@gmail.com>
 <7FA8E1ACC4330226FD4A5EEE@PSB>
 <9a0d142e-057d-44f3-af6b-db72a603ecfd@gmail.com>
 <E51C0C7A3E6342A9B146569D@PSB>
To: "John C. Klensin" <john-ietf@jck.com>
Message-ID-Hash: 7PA7Q3D7USC2IGU6YIKLOVTEB7H2CBCX
CC: ietf <ietf@ietf.org>, chair@ietf.org
Precedence: list
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ietf/O26MylJYzrSFeVIxyuAr72j-TjI>

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=20=

members that said (in so many words)=20

'the IESG wants you to stop doing this'=20

about the Klensin proposal - nothing about community considerations -=20
i.e a specific example of what John describes as the IESG substituting =
its=20
judgement or preferences over any community considerations

Scott

> On Aug 20, 2024, at 9:16=E2=80=AFAM, John C Klensin =
<john-ietf@jck.com> wrote:
>=20
> Brian,
>=20
> A few comments inline below, with considerable agreement but perhaps
> with a tad less optimism...
>=20
> --On Tuesday, August 20, 2024 17:20 +1200 Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
>=20
>> John,
>>=20
>>> 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.
>>=20
>> (I've left the rest of John's message below in case anyone needs
>> more context.)
>>=20
>> 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.
>>=20
>> The result was this:
>> https://mailarchive.ietf.org/arch/msg/newtrk/j8Si3b0cqnQSX5a5Ee8NIV
>> dyZg4/
>>=20
>> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>> 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.
>=20
> Yes.  See above.  And I think that puts us more or less in agreement
> so far.
>=20
>> After
>> NEWTRK was formally closed, I made a couple of attempts to start
>> non-WG efforts (baptised PESCI and PUFI) but they failed.
>>=20
>> 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.
>=20
> 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.
>=20
>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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)=20
>=20
>=20
>> *In April/May 2005 when the above email was composed, only two
>> or three IESG members were on the NEWTRK list.*
>>=20
>> 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.
>=20
> 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.
>=20
> best,
>   john
>=20