On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote:
> > On 27 Mar 2023, at 16:46, Scott Kitterman <ietf-d...@kitterman.com> wrote:
> > 
> > On March 27, 2023 3:10:40 PM UTC, Laura Atkins <la...@wordtothewise.com> 
wrote:
> >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy <superu...@gmail.com>
> >>> wrote:
> >>> 
> >>> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas <m...@mtcc.com 
<mailto:m...@mtcc.com>> 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.
> >>>> 
> >>>> There isn't a place in the charter/milestones for that.
> >>> 
> >>> The charter identifies these possible outputs in some combination:
> >>> 
> >>> (1) a clear problem statement;
> >>> 
> >>> (2) one or more protocol update document(s);
> >>> 
> >>> (3) a statement of some kind that the WG determined no feasible protocol
> >>> solution exists (and, one would hope, how it reached this conclusion);
> >>> 
> >>> (4) an update to current DKIM operational advice with respect to the
> >>> stated problem.
> >>> 
> >>> The only constraint in the charter is that (2) and (3) are mutually
> >>> exclusive.>> 
> >> Agreed with all of this.
> >> 
> >>> I believe that a history of what techniques were previously tried and
> >>> failed could arguably go into any of them.  The charter is neither
> >>> prescriptive or proscriptive on this point.>> 
> >> 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.
> We have two documents that are up for debate as the working group draft.
> Anyone else is welcome to provide an alternative for consideration as well
> - as Dave did and that is now being wrapped into Wei’s draft.
> > Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before
> > investing any more time on the problem statement.  I think it would make
> > sense for the group to do a quick assessment of it, when it is available
> > and see if we want to adopt it as a working group draft (I strongly
> > suspect we do).
> That’s my feeling as well, particularly given no one else is stepping up to
> write a draft of the problem statement on behalf of the working group. If
> someone does have an alternative in progress please let me know.

Do you plan adopt it as a working group draft?  That's a critical step in the 
process.  Anything before that step needn't reflect anything other than the 
author's opinion (and that's optional).

Scott K



_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to