Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

The warning that was issued was perfectly appropriate for a chair to issue. And it appears to have been issued in consultation with the other chairs and AD as is fair. The only thing that remains is for some other chair to have issued the warning. From: Michael Thomas Date: Wednesday, 29

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/28/23 7:16 PM, Suresh Ramasubramanian wrote: Let me clarify that 1. I think Mike’s tone to have been aggressive in this, and not constructive.  I would support an official warning being issued. 2. I also think that, as Scott pointed out, when Laura as a wg member has disagreed

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

Let me clarify that 1. I think Mike’s tone to have been aggressive in this, and not constructive. I would support an official warning being issued. 2. I also think that, as Scott pointed out, when Laura as a wg member has disagreed with Mike, in the interest of fairness, she should let

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

I would request that both the parties in this disengage and refer this to the other group chairs. While a difference of opinion on what is and is not in scope for this WG is fine, this conversation has taken an ugly turn at this point. From: Ietf-dkim on behalf of Michael Thomas Date:

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

I would like the rest of the working group to know what is considered unconstructive behavior by the chair: "The current discussion on the table is for the problem statement. You are welcome to constructively contribute to the wording of the problem statement. Your recent posts including the

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

You are correct and I apologize. I did send a message, but your address was omitted from the to: list. That is my error and I am very sorry. I will forward you a copy of the message you should have received offlist. As for the rest, both Murray and Tim are participating in IETF 116 at the

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/28/23 2:31 AM, 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,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

Very nicely put, Scott. I was also thinking this action ought to be be initiated by someone else in authority, probably either Tim or Murray, if it is appropriate. The timing of this warning also unfortunately makes it seem like it comes at the behest of another working group participant,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

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

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

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.

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/27/23 5:34 PM, Murray S. Kucherawy wrote: On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote: 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

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/27/2023 3:07 PM, Barry Leiba wrote: o you understand what "disingenuous" means? Do you really think someone is intentionally acting in bad faith? Barry, your question carries a possible implication that there is some way the that word was contained in was other than an ad hominem. I

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote: > 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. > The milestones are negotiable, but

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

Do you understand what "disingenuous" means? Do you really think someone is intentionally acting in bad faith? Barry On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote: > > > On 3/27/23 8:46 AM, Scott Kitterman wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins > > wrote: > >> >

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

Sent from my iPhone > On Mar 27, 2023, at 6:40 PM, Scott Kitterman wrote: > > On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote: On 27 Mar 2023, at 16:46, Scott Kitterman wrote: >>> >>> On March 27, 2023 3:10:40 PM UTC, Laura Atkins > wrote: > On 26 Mar 2023, at

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote: > > On 27 Mar 2023, at 16:46, Scott Kitterman wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins wrote: > >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy > >>> wrote: > >>> > >>> On Sat, Mar 25, 2023 at 10:29 AM

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On 27 Mar 2023, at 16:46, Scott Kitterman wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins > wrote: >> >> >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy wrote: >>> >>> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas >> > wrote: On 3/24/23

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/27/23 8:46 AM, Scott Kitterman wrote: On March 27, 2023 3:10:40 PM UTC, Laura Atkins 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

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On March 27, 2023 3:10:40 PM UTC, Laura Atkins wrote: > > >> On 26 Mar 2023, at 11:13, Murray S. Kucherawy wrote: >> >> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > > wrote: >>> On 3/24/23 6:19 PM, Barry Leiba wrote: >>> > I don't agree with the premise. I think

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On 26 Mar 2023, at 11:13, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 1:11 PM, Michael Thomas wrote: > My contention is that documenting what has failed in the problem statement > saves time eventually in the solution space as you can reference it when > somebody brings it up as to why it doesn't work. It would be just a cut and > paste

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/26/23 3:13 AM, Murray S. Kucherawy wrote: On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas wrote: On 3/24/23 6:19 PM, Barry Leiba wrote: > I don't agree with the premise.  I think what was tried and didn't > work should be documented in the result that the working group comes

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas wrote: > On 3/24/23 6:19 PM, Barry Leiba wrote: > > I don't agree with the premise. I think what was tried and didn't > > work should be documented in the result that the working group comes > > out with, but not in the problem statement. > >

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/25/23 11:25 AM, Scott Kitterman wrote: On March 25, 2023 3:13:11 PM UTC, Michael Thomas wrote: On 3/24/23 9:10 PM, Jim Fenton wrote: On 25 Mar 2023, at 8:57, Michael Thomas wrote: Somebody brought up that this could turn into a research project. Frankly I think that is highly likely

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On March 25, 2023 3:13:11 PM UTC, Michael Thomas wrote: > >On 3/24/23 9:10 PM, Jim Fenton wrote: >> On 25 Mar 2023, at 8:57, Michael Thomas wrote: >> >>> Somebody brought up that this could turn into a research project. Frankly I >>> think that is highly likely the case and is why

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/24/23 9:10 PM, Jim Fenton wrote: On 25 Mar 2023, at 8:57, Michael Thomas wrote: Somebody brought up that this could turn into a research project. Frankly I think that is highly likely the case and is why rechartering was so problematic. Since M3AAWG can't figure it out with lots of

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/25/23 2:46 AM, Laura Atkins wrote: I asked yesterday for commentary on the drafts as an attempt to move the discussion forward so we could discuss the shape and scope of the current proposals. I would politely request that you confine discussions of the shape and scope to that thread,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

+1 > On 25 Mar 2023, at 01:19, Barry Leiba wrote: > > I don't agree with the premise. I think what was tried and didn't > work should be documented in the result that the working group comes > out with, but not in the problem statement. > > Barry > > On Sat, Mar 25, 2023 at 8:57 AM Michael

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

I asked yesterday for commentary on the drafts as an attempt to move the discussion forward so we could discuss the shape and scope of the current proposals. I would politely request that you confine discussions of the shape and scope to that thread, rather than staring yet a different thread.

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 25 Mar 2023, at 8:57, Michael Thomas wrote: > Somebody brought up that this could turn into a research project. Frankly I > think that is highly likely the case and is why rechartering was so > problematic. Since M3AAWG can't figure it out with lots of inside the > industry information,

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

On 3/24/23 6:19 PM, Barry Leiba wrote: I don't agree with the premise. I think what was tried and didn't work should be documented in the result that the working group comes out with, but not in the problem statement. There isn't a place in the charter/milestones for that. When I proposed

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

I don't agree with the premise. I think what was tried and didn't work should be documented in the result that the working group comes out with, but not in the problem statement. Barry On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas wrote: > > > And yes, that means spam filters and the rest of

[Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

And yes, that means spam filters and the rest of the ecosystem around email in which DKIM operates. As in, why exactly are we here? Why can't industry groups come up with their own solutions? We either document it now, or argue about it later especially when it becomes plain that there is