And, fwiw, I agree with that too but, since a non-trivial number of people seem concerned about various scenarios and what precedents and/or long-term damage they might stick us with, it seems to me that a reasonable solution would be the one I proposed: Assume that the current IESG, and particular Murray, have things under control, that any actual risks about about the future, and modify things only to the extent of explicitly planning to review the WG and its charter when Murray (and possibly other IESG members) are replaced. With some fresh eyes and much of a year worth of experience, we should be able to, at least, have a more constructive and less paranoid discussion. For the present, that would let the WG get moving on matters of substance under the current charter and without more fuss, which I think is consistent with what both you and Rob have suggested. If we have to have more of this discussion, let's have it after we have some experience. best, john --On Monday, May 27, 2024 00:15 +0100 Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > FWIW, I think Rob's take below matches mine. Trying this out > to see if it works seems worth a shot and given chartering > followed the usual process I see no reason to second-guess > IETF consensus to form this WG with this charter. > > Cheers, > S. > > On 24/05/2024 15:41, Rob Wilton (rwilton) wrote: >> Hi Keith, >> >> Perhaps the proponents for the WG looked at what IDR was doing, >> thought that seems to work well, and they should try something >> similar here? I.e., there does seems to be some supporting >> analysis that this approach may work well for mature, widely >> deployed technologies. Is there any recent evidence that this >> approach has been tried and hasn't worked? >> >> But equally, maybe this feedback would have been better during the >> community review phase in April, i.e., BEFORE the WG was chartered? >> I.e., the premise here seems to be that this is such a terrible >> precedent that the IESG should ignore the normal rules and process >> for chartering the WG and make up some new ones on the fly that >> allow the charter to be modified after the WG has completed all >> the steps specified in the process. This hardly feels justified >> in the case where we don't actually know that the current >> charter is a problem, only a supposition that it will be. >> >> I can't see why the best option here isn't just to try it out >> and see what happens. If the requirement turns out to be too >> restrictive then the WG can always be rechartered to tweak the >> process or remove it altogether. But I'm not even convinced >> that there will even be an issue here at all ... >> >> Regards, Rob >> >> >> >> From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> Date: Friday, 24 May >> 2024 at 14:41 To: ietf@xxxxxxxx <ietf@xxxxxxxx> Subject: Re: >> [Ietf-dkim] WG Action: Formed Mail Maintenance (mailmaint) / >> Commitment On 5/23/24 15:47, John Scudder wrote: >> >>> Sometimes we should be brave enough to try new things. Maybe this >>> is one of those times? >> I don't think bravery is the issue here. The question in my mind >> is, does this actually help make IETF standards developed by this >> WG more relevant to the Internet? >> >> So far, I fail to see how it does. >> >> Existence of independent prototype implementations is a nearly >> necessary, but far from sufficient, condition, for ensuring that. >> >> (I say "nearly" necessary because it's actually possible for a >> protocol to be successful in market terms even if there's really >> only one implementation - heck this is almost true for web browsers >> today.) >> >> Or to put it in terms of bravery, sometimes we should be brave >> enough to NOT do whatever strikes someone as a good idea, without >> first doing some analysis to see whether it actually helps. And >> I mean no criticism of whoever thought this was a good idea. But >> fundamentally the practice of engineering is to use analysis to >> determine what will work well, BEFORE it's actually implemented. >> >> Keith >> >>
