Re: [Ietf-dkim] Clarifying the problem

On 3/25/23 8:17 PM, Murray S. Kucherawy wrote: On Fri, Mar 24, 2023, 10:10 Michael Thomas wrote: 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 focu

Re: [Ietf-dkim] Clarifying the problem

On Fri, Mar 24, 2023, 10:10 Michael Thomas wrote: > 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

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 rechartering

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 insi

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

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 Th

Re: [Ietf-dkim] Problem statement adoption

On Fri 24/Mar/2023 18:42:28 +0100 Dave Crocker wrote: 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 ne

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

> On 24 Mar 2023, at 16:38, Murray S. Kucherawy wrote: > > 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

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.