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

2023-03-27 Thread Michael Thomas 


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 result is... disingenuous.


The milestones are negotiable, but if the chairs would prefer not to 
do so and instead choose to try to push the WG to meet the current 
target, that is their prerogative.


I echo Barry's question.

Considering that the shape of the problem statement and its contents 
haven't even been discussed, saying that I should be limited it to 
"submit text" with this post is not an appropriate response. Oh, and the 
tiny problem that there isn't even a working group document to submit 
text to. How does that work?


Make of that what you will.

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

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

2023-03-27 Thread Dave Crocker 

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 am pretty sure there isn't one.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

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

2023-03-27 Thread Murray S. Kucherawy 
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 if the chairs would prefer not to do so
and instead choose to try to push the WG to meet the current target, that
is their prerogative.

I echo Barry's question.

-MSK, ART AD
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

2023-03-27 Thread Barry Leiba 
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:
> >>
> >> 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

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

2023-03-27 Thread Laura Atkins 


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 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 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).

In the absence of a competing draft and if that’s the consensus of the group, 
yes. 

Laura

> 
> Scott K
> 
> 
> 
> ___
> 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

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

2023-03-27 Thread Scott Kitterman 
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 Michael Thomas 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

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

2023-03-27 Thread Laura Atkins 


> 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 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. 

> Once that's done, I think there will be a solid basis for progress towards 
> the milestone.  
> 
> In the meantime, if someone wants to write up a section on what's been tried, 
> I don't think it's on the critical path for the milestone until there's 
> agreement to add it to the document.  It certainly doesn't delay anything now 
> while we're waiting for the -02 of the problem statement.  If the text can be 
> developed in parallel, it might not affect the schedule significantly.  
> Myself, if we can, I think we should (I will volunteer to review and provide 
> feedback on this but not to write it - I don't have the time).

That makes sense and I support doing the work in parallel. 

Do we have volunteers to write up some of what’s been tried?

laura

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

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

2023-03-27 Thread Michael Thomas 


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

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

2023-03-27 Thread Scott Kitterman 


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 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.

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).

Once that's done, I think there will be a solid basis for progress towards the 
milestone.  

In the meantime, if someone wants to write up a section on what's been tried, I 
don't think it's on the critical path for the milestone until there's agreement 
to add it to the document.  It certainly doesn't delay anything now while we're 
waiting for the -02 of the problem statement.  If the text can be developed in 
parallel, it might not affect the schedule significantly.  Myself, if we can, I 
think we should (I will volunteer to review and provide feedback on this but 
not to write it - I don't have the time).

Scott K

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

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

2023-03-27 Thread Laura Atkins 


> 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 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. 

laura (as chair) 


-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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