I am attempting to tread carefully here. My success in doing so is historically quite mixed, so if I fail, apologies in advance.
In my view Micheal has challenged your approach to some of your decisions in a very sharp manner (which I don't support). In general, I think if a working group chair is party to a dispute, it's better for the other chair to address it. When you are both a party to the dispute and use your authority to address it, it (at the very least) creates a potential perception of impropriety. If we imagine a world where Michael's accusation is literally true and you were trying to shut down any discussion of alternatives to some pre-conceived result you've already decided on, this is precisely what the next step would be. My request is that you withdraw this and ask Tim to send it instead if he thinks it's appropriate. Personally, I found your response to him in Message-Id: <86ff4071-0720-4cde-9815-f7c472171...@wordtothewise.com> pretty harsh, particularly when two days later in Message-Id: <CB17F4B2-2D38-45ED- b323-115e5196b...@wordtothewise.com> you agreed with me that it was reasonable to wait for the next revision of draft-chuang-dkim-replay-problem before working on it further. Based on what you've said in those two messages, I understand your direction to the working group is to only talk about specific text changes to the non-WG draft, but you also agree there's really not much point in doing so. Rather than take steps to push a contributor with a lot of relevant domain knowledge out of the group (which is precisely what this is, intended or not), I would encourage the chairs to work towards reducing the emotional energy in the group. I think that would be more useful than process threats. I am honestly wondering if I want to keep doing this. Scott K On Tuesday, March 28, 2023 5:31:07 AM EDT Laura Atkins wrote: > Dear Michael, > > Your message of 27 March quoted in its entirety below, included _ad hominem_ > attacks against another participant. _Ad hominem_ is a fallacious form of > argument wherein the person arguing attacks the person holding an opposing > position, rather than attacking the position itself. This is not > acceptable, and you have been warned before. I contacted you off-list on > behalf of the chairs, under the procedures in BCP 25, but you have refused > to take what we regard as rectifying action. > > Accordingly, please understand this message as a formal warning under the > procedures of BCP 25 that, if we observe continued behaviour of the sort > you have exhibited, we shall suspend your posting privileges to the > dkim-ietf mailing list for 30 days. Behaviour of the sort includes > anything that we believe to be needlessly personalized, and especially > includes _ad hominem_ forms of argument. We will also treat returning to > points that have been closed without raising new arguments as attempts to > disrput the functioning of the Working Group. > > We will act without further warning in such an event. > > If we take that action, and, after restoration of your privileges, we > observe you to return to disrupting the work of the group, we shall > undertake action under BCP 25. > > Sincerely, > > Laura (for the chairs) > > > On 27 Mar 2023, at 17:04, Michael Thomas <m...@mtcc.com> wrote: > > > > On 3/27/23 8:46 AM, Scott Kitterman wrote: > >> On March 27, 2023 3:10:40 PM UTC, Laura Atkins <la...@wordtothewise.com> wrote: > >>> It seems to me a history of what did work / didn’t will go into document > >>> 4 or the reasoning for document 3. My current preference is for the > >>> discussion to not be in the problem statement. My reasoning is that > >>> there will be discussion about what didn’t work and why it didn’t work. > >>> I expect that there will be quite a bit of back and forth to capture > >>> the details of why something didn’t work - including the adaptations > >>> that the attackers made to the changes. This, to my mind, is the job of > >>> the working group: to look at the current status, discuss where the > >>> holes are and if they are protocol holes or if they are best practice / > >>> implementation holes. > >>> > >>> On a more practical point, we have a month to finalize the problem > >>> statement. No one has proposed language to include in the problem > >>> statement about what has worked and what hasn’t worked. Given the > >>> current state of the group, I simply don’t think we have the time to > >>> put this into the problem statement and get it out in time. > >>> > >>> I do think we have the time and space to discuss techniques after the > >>> problem statement is done and include it in one of the WG output > >>> documents.>> > >> So far, unless I was napping when it happened, we don't have a working > >> group draft of the problem statement.> > > Exactly. It's rather disingenuous to require people to propose text to a > > non-working group document especially since we don't know what is going > > to be in a next version since it doesn't have to track the consensus of > > the working group. > > > > Also: it's disingenuous to demand text for something that the scope has > > not even been established. It also assumes that we know the answers which > > we don't. My post was trying to get some of those answers but it wasn't > > enough, and may well have missed many pertinent things since I'm not an > > industry insider. The intent of my questions was start an inquiry into > > that state that could be used as input. > > > > Lastly: cutting off debate because of time is bogus. Murray already said > > that the milestone dates were fairly arbitrary. Using them as a tool to > > get the chair's preferred result is... disingenuous. > > > > Mike > > > > _______________________________________________ > > Ietf-dkim mailing list > > Ietf-dkim@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
