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, what

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 th

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 t

[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 no

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

> On 24 Mar 2023, at 18:14, Scott Kitterman wrote: > > > > On March 24, 2023 5:42:41 PM UTC, Michael Thomas wrote: >> >> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote: >>> >>> >>> Fine with me, it's far from a showstopper overall. I just made the >>> suggestion. >>> >> This wg should

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

+1. ARC is not a solution, but it is a good part of the problem. It’s not hard to see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model in lieu of Reputation Modeling creating this issue. Every issue we have today is nearly 100% because of the lob-sided efforts to impos

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

On March 24, 2023 5:42:41 PM UTC, Michael Thomas wrote: > >On 3/24/23 10:22 AM, Murray S. Kucherawy wrote: >> >> >> Fine with me, it's far from a showstopper overall.  I just made the >> suggestion. >> >This wg should be concerned with DKIM problems, not other wg problems and >especially fo

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

On 3/24/23 10:22 AM, Murray S. Kucherawy wrote: Fine with me, it's far from a showstopper overall.  I just made the suggestion. This wg should be concerned with DKIM problems, not other wg problems and especially for experimental rfc's of dubious value and complete mysteries as to what th

Re: [Ietf-dkim] Problem statement adoption

On 3/24/2023 6:45 AM, Dave Crocker wrote: On 3/24/2023 6:42 AM, Laura Atkins wrote: We currently have two problem statements to discuss for adoption. Wei is merging 'mine' into his.  (Note mine was done as a variant of his.) For folks new to IETF processes, it might be worth explaining that

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

On Fri, Mar 24, 2023 at 9:59 AM Dave Crocker wrote: > On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote: > > I think I concur with the suggestion that wa should drop discussion of > > ARC. This WG, or the DMARC WG, can develop an update to ARC based on > > the outcome here if the community chooses

Re: [Ietf-dkim] Problem statement adoption

Neither in their current forms. They are far too vague. They don't specify what has been tried and/or are not adequate or don't work. They should not be considered as the only two options. Also: potential BCP's are in scope via the charter. That requires way more information than any supposed

Re: [Ietf-dkim] Clarifying the problem

On 3/24/23 9:58 AM, Laura Atkins wrote: On 24 Mar 2023, at 16:48, Michael Thomas wrote: On 3/24/23 6:14 AM, Laura Atkins wrote: Please, let’s focus on the current issue with is addressing  and refining the problem statement. So you agree with me that any discussion of ARC and its comple

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

Murray, I'll skip over comments that I think will be resolved as Wei incorporates my text or that I don't have a useful comment on... On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote: I think I concur with the suggestion that wa should drop discussion of ARC.  This WG, or the DMARC WG, can dev

Re: [Ietf-dkim] Clarifying the problem

> On 24 Mar 2023, at 16:48, Michael Thomas wrote: > > > On 3/24/23 6:14 AM, Laura Atkins wrote: >> Please, let’s focus on the current issue with is addressing and refining >> the problem statement. > > So you agree with me that any discussion of ARC and its complete failings > should be ou

Re: [Ietf-dkim] Process Questions

On 3/24/23 6:15 AM, Laura Atkins wrote: On 10 Mar 2023, at 00:30, Michael Thomas wrote: Now that we have a chair, I have a question about process wrt to the charter. The charter states that either the working group will produce documents addressin

Re: [Ietf-dkim] Clarifying the problem

On 3/24/23 6:14 AM, Laura Atkins wrote: Please, let’s focus on the current issue with is addressing  and refining the problem statement. So you agree with me that any discussion of ARC and its complete failings should be out of scope? I would appreciate the chairs enforcing that. Mike ___

[Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

Informal comments only here. I know a merger with Dave's draft is in progress, so some of these may not apply by the time you're done. Section 1.1: It feels a little presumptuous to assume any DKIM receiver has also built out a reputation system, or has access to one. I guess it might depend on

Re: [Ietf-dkim] Problem statement adoption

Great! Thanks. laura > On 24 Mar 2023, at 14:14, Wei Chuang wrote: > > +1 I'm working on it. > > -wei > > On Fri, Mar 24, 2023, 6:45 AM Dave Crocker > wrote: >> On 3/24/2023 6:42 AM, Laura Atkins wrote: >> > We currently have two problem statements to discuss for

Re: [Ietf-dkim] Problem statement adoption

+1 I'm working on it. -wei On Fri, Mar 24, 2023, 6:45 AM Dave Crocker wrote: > On 3/24/2023 6:42 AM, Laura Atkins wrote: > > We currently have two problem statements to discuss for adoption. > > Wei is merging 'mine' into his. (Note mine was done as a variant of his.) > > I believe there will

Re: [Ietf-dkim] Problem statement adoption

On 3/24/2023 6:42 AM, Laura Atkins wrote: We currently have two problem statements to discuss for adoption. Wei is merging 'mine' into his.  (Note mine was done as a variant of his.) I believe there will again be only one draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@d

[Ietf-dkim] Problem statement adoption

We currently have two problem statements to discuss for adoption. In order to move the adoption forward can we get some specific consensus on the drafts that we currently have on the table or some specific wording changes needed before adoption. The drafts on the table: Draft 1: https://dat

Re: [Ietf-dkim] Process Questions

>>> On 10 Mar 2023, at 00:30, Michael Thomas wrote: Now that we have a chair, I have a question about process wrt to the charter. The charter states that either the working group will produce documents addressing the problem, or it will pro

Re: [Ietf-dkim] Clarifying the problem

Please, let’s focus on the current issue with is addressing and refining the problem statement. laura > On 23 Mar 2023, at 20:27, Michael Thomas wrote: > > > On 3/23/23 2:52 AM, Alessandro Vesely wrote: >> On Wed 22/Mar/2023 20:31:51 +0100 Michael Thomas wrote: >>> On 3/21/23 8:01 PM, Mur