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

[Suresh Ramasubramanian]

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 March 2023 at 7:51 AM
To: Suresh Ramasubramanian , Laura Atkins 

Cc: ietf-dkim@ietf.org 
Subject: 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 with Mike, in the interest of fairness, she should let one of the 
other chairs warn Mike.

She is not speaking as a working group member. She is speaking as a chair. That 
is the problem. Especially saying to "submit text" to a working group document 
that doesn't even exist. That is a problem with process and needs to be 
addressed.

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

[Michael Thomas]

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 with Mike, in the interest of fairness, she should
let one of the other chairs warn Mike.

She is not speaking as a working group member. She is speaking as a 
chair. That is the problem. Especially saying to "submit text" to a 
working group document that doesn't even exist. That is a problem with 
process and needs to be addressed.


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

[Suresh Ramasubramanian]

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 one of the 
other chairs warn Mike.

thanks
--srs

From: Suresh Ramasubramanian 
Date: Wednesday, 29 March 2023 at 7:34 AM
To: Michael Thomas , Laura Atkins 
Cc: ietf-dkim@ietf.org 
Subject: 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: Wednesday, 29 March 2023 at 7:14 AM
To: Laura Atkins 
Cc: ietf-dkim@ietf.org 
Subject: 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 emails at:

* https://mailarchive.ietf.org/arch/msg/ietf-dkim/EUTsQgJ8gdtJY16UdiWxHKLr9E4/

'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 protocol solution. Since that is by

far the most likely output of this, dismissing any talk of them is

violating the stated charter.'
* https://mailarchive.ietf.org/arch/msg/ietf-dkim/NM7tXBcefGA7dOhhUV7QkvSJSns/

'Maybe you should have a conversation with your AD who brought up ARC in

one of the threads here.'

* https://mailarchive.ietf.org/arch/msg/ietf-dkim/HVA6D6PNVNE5S7AQQ7i_kaq2TlU/


'As I've said, the two proposed problem statements are far too vague.

It's not about wordsmithing them. It's about having something that

actually discusses what is known about the problem.



And BTW: the charter says that a BCP is in scope. That is not a "side

discussion".'
are not constructive contributions to the discussion. As you are not new to 
participating in the IETF I trust you understand what constructive comments 
are. Constructive comments include specific wording and scope changes that you 
would like the group to consider. Comments such as the above are not 
constructive and must stop."

This was all while I was trying to get clarity and scope discussions so that 
the problem statement would be less vague.

This is process run amok.

Mike
On 3/28/23 12:01 PM, Laura Atkins wrote:
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 
moment. I have been in contact with Murray throughout this process and have 
taken the actions I have with his guidance and approval.

Again, I apologize that I was not careful in sending the email yesterday and 
left your address off the cc list.

laura



On 28 Mar 2023, at 19:34, Michael Thomas  
wrote:



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, rather than attacking the position itself.  This is not acceptable, 
and you have been warned before.  I contacted you off-list on behalf of the 
chairs, under the procedures in BCP 25, but you have refused to take what we 
regard as rectifying action.

I have not been contacted off-list. Surely you can produce evidence. It is not 
in my spam folder either.


Mike


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

[Suresh Ramasubramanian]

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: Wednesday, 29 March 2023 at 7:14 AM
To: Laura Atkins 
Cc: ietf-dkim@ietf.org 
Subject: 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 emails at:

* https://mailarchive.ietf.org/arch/msg/ietf-dkim/EUTsQgJ8gdtJY16UdiWxHKLr9E4/

'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 protocol solution. Since that is by

far the most likely output of this, dismissing any talk of them is

violating the stated charter.'
* https://mailarchive.ietf.org/arch/msg/ietf-dkim/NM7tXBcefGA7dOhhUV7QkvSJSns/

'Maybe you should have a conversation with your AD who brought up ARC in

one of the threads here.'

* https://mailarchive.ietf.org/arch/msg/ietf-dkim/HVA6D6PNVNE5S7AQQ7i_kaq2TlU/


'As I've said, the two proposed problem statements are far too vague.

It's not about wordsmithing them. It's about having something that

actually discusses what is known about the problem.



And BTW: the charter says that a BCP is in scope. That is not a "side

discussion".'
are not constructive contributions to the discussion. As you are not new to 
participating in the IETF I trust you understand what constructive comments 
are. Constructive comments include specific wording and scope changes that you 
would like the group to consider. Comments such as the above are not 
constructive and must stop."

This was all while I was trying to get clarity and scope discussions so that 
the problem statement would be less vague.

This is process run amok.

Mike
On 3/28/23 12:01 PM, Laura Atkins wrote:
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 
moment. I have been in contact with Murray throughout this process and have 
taken the actions I have with his guidance and approval.

Again, I apologize that I was not careful in sending the email yesterday and 
left your address off the cc list.

laura


On 28 Mar 2023, at 19:34, Michael Thomas  
wrote:



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, rather than attacking the position itself.  This is not acceptable, 
and you have been warned before.  I contacted you off-list on behalf of the 
chairs, under the procedures in BCP 25, but you have refused to take what we 
regard as rectifying action.

I have not been contacted off-list. Surely you can produce evidence. It is not 
in my spam folder either.


Mike


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

[Michael Thomas]

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 emails at:


* 
https://mailarchive.ietf.org/arch/msg/ietf-dkim/EUTsQgJ8gdtJY16UdiWxHKLr9E4/


'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 protocol solution. Since that is by
far the most likely output of this, dismissing any talk of them is
violating the stated charter.'

* 
https://mailarchive.ietf.org/arch/msg/ietf-dkim/NM7tXBcefGA7dOhhUV7QkvSJSns/


'Maybe you should have a conversation with your AD who brought up ARC in
one of the threads here.'


* 
https://mailarchive.ietf.org/arch/msg/ietf-dkim/HVA6D6PNVNE5S7AQQ7i_kaq2TlU/


'As I've said, the two proposed problem statements are far too vague.
It's not about wordsmithing them. It's about having something that
actually discusses what is known about the problem.

And BTW: the charter says that a BCP is in scope. That is not a "side
discussion".'

are not constructive contributions to the discussion. As you are not new 
to participating in the IETF I trust you understand what constructive 
comments are. Constructive comments include specific wording and scope 
changes that you would like the group to consider. Comments such as the 
above are not constructive and must stop."


This was all while I was trying to get clarity and scope discussions so 
that the problem statement would be less vague.


This is process run amok.

Mike

On 3/28/23 12:01 PM, Laura Atkins wrote:
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 moment. I have been in contact with Murray throughout this process 
and have taken the actions I have with his guidance and approval.


Again, I apologize that I was not careful in sending the email 
yesterday and left your address off the cc list.


laura


On 28 Mar 2023, at 19:34, Michael Thomas  wrote:


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, rather than attacking the 
position itself.  This is not acceptable, and you have been warned 
before.  I contacted you off-list on behalf of the chairs, under the 
procedures in BCP 25, but you have refused to take what we regard as 
rectifying action.


I have not been contacted off-list. Surely you can produce evidence. 
It is not in my spam folder either.



Mike




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

[Laura Atkins]

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 
moment. I have been in contact with Murray throughout this process and have 
taken the actions I have with his guidance and approval. 

Again, I apologize that I was not careful in sending the email yesterday and 
left your address off the cc list. 

laura 

> On 28 Mar 2023, at 19:34, Michael Thomas  wrote:
> 
> 
> 
> 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, rather than attacking the position itself.  This is not 
>> acceptable, and you have been warned before.  I contacted you off-list on 
>> behalf of the chairs, under the procedures in BCP 25, but you have refused 
>> to take what we regard as rectifying action.
> I have not been contacted off-list. Surely you can produce evidence. It is 
> not in my spam folder either.
> 
> 
> Mike
> 
> 

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

[Michael Thomas]

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, rather than attacking the 
position itself.  This is not acceptable, and you have been warned 
before.  I contacted you off-list on behalf of the chairs, under the 
procedures in BCP 25, but you have refused to take what we regard as 
rectifying action.


I have not been contacted off-list. Surely you can produce evidence. It 
is not in my spam folder either.



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

[Jim Fenton]

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, while it is of course the WG 
chairs’ (or AD) responsibility to make this determination.

-Jim

On 28 Mar 2023, at 22:21, Scott Kitterman wrote:

> 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 chair is party to a dispute, it's better for the other chair to address
> it.  When you are both a party to the dispute and use your authority to
> address it, it (at the very least) creates a potential perception of
> impropriety.
>
> If we imagine a world where Michael's accusation is literally true and you
> were trying to shut down any discussion of alternatives to some pre-conceived
> result you've already decided on, this is precisely what the next step would
> be.
>
> My request is that you withdraw this and ask Tim to send it instead if he
> thinks it's appropriate.
>
> Personally, I found your response to him in Message-Id:
> <86ff4071-0720-4cde-9815-f7c472171...@wordtothewise.com> pretty harsh,
> particularly when two days later in Message-Id:  b323-115e5196b...@wordtothewise.com> you agreed with me that it was reasonable
> to wait for the next revision of draft-chuang-dkim-replay-problem before
> working on it further.
>
> Based on what you've said in those two messages, I understand your direction
> to the working group is to only talk about specific text changes to the non-WG
> draft, but you also agree there's really not much point in doing so.
>
> Rather than take steps to push a contributor with a lot of relevant domain
> knowledge out of the group (which is precisely what this is, intended or not),
> I would encourage the chairs to work towards reducing the emotional energy in
> the group.  I think that would be more useful than process threats.
>
> I am honestly wondering if I want to keep doing this.
>
> Scott K
>
> On Tuesday, March 28, 2023 5:31:07 AM EDT 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, rather than attacking the position itself.  This is not
>> acceptable, and you have been warned before.  I contacted you off-list on
>> behalf of the chairs, under the procedures in BCP 25, but you have refused
>> to take what we regard as rectifying action.
>>
>> Accordingly, please understand this message as a formal warning under the
>> procedures of BCP 25 that, if we observe continued behaviour of the sort
>> you have exhibited, we shall suspend your posting privileges to the
>> dkim-ietf mailing list for 30 days.  Behaviour of the sort includes
>> anything that we believe to be needlessly personalized, and especially
>> includes _ad hominem_ forms of argument.  We will also treat returning to
>> points that have been closed without raising new arguments as attempts to
>> disrput the functioning of the Working Group.
>>
>> We will act without further warning in such an event.
>>
>> If we take that action, and, after restoration of your privileges, we
>> observe you to return to disrupting the work of the group, we shall
>> undertake action under BCP 25.
>>
>> Sincerely,
>>
>> Laura (for the chairs)
>>
>>> On 27 Mar 2023, at 17:04, 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 

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

[Scott Kitterman]

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 chair is party to a dispute, it's better for the other chair to address 
it.  When you are both a party to the dispute and use your authority to 
address it, it (at the very least) creates a potential perception of 
impropriety.

If we imagine a world where Michael's accusation is literally true and you 
were trying to shut down any discussion of alternatives to some pre-conceived 
result you've already decided on, this is precisely what the next step would 
be.

My request is that you withdraw this and ask Tim to send it instead if he 
thinks it's appropriate.

Personally, I found your response to him in Message-Id: 
<86ff4071-0720-4cde-9815-f7c472171...@wordtothewise.com> pretty harsh, 
particularly when two days later in Message-Id:  you agreed with me that it was reasonable 
to wait for the next revision of draft-chuang-dkim-replay-problem before 
working on it further.

Based on what you've said in those two messages, I understand your direction 
to the working group is to only talk about specific text changes to the non-WG 
draft, but you also agree there's really not much point in doing so.

Rather than take steps to push a contributor with a lot of relevant domain 
knowledge out of the group (which is precisely what this is, intended or not), 
I would encourage the chairs to work towards reducing the emotional energy in 
the group.  I think that would be more useful than process threats.

I am honestly wondering if I want to keep doing this.

Scott K

On Tuesday, March 28, 2023 5:31:07 AM EDT 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, rather than attacking the position itself.  This is not
> acceptable, and you have been warned before.  I contacted you off-list on
> behalf of the chairs, under the procedures in BCP 25, but you have refused
> to take what we regard as rectifying action.
> 
> Accordingly, please understand this message as a formal warning under the
> procedures of BCP 25 that, if we observe continued behaviour of the sort
> you have exhibited, we shall suspend your posting privileges to the
> dkim-ietf mailing list for 30 days.  Behaviour of the sort includes
> anything that we believe to be needlessly personalized, and especially
> includes _ad hominem_ forms of argument.  We will also treat returning to
> points that have been closed without raising new arguments as attempts to
> disrput the functioning of the Working Group.
> 
> We will act without further warning in such an event.
> 
> If we take that action, and, after restoration of your privileges, we
> observe you to return to disrupting the work of the group, we shall
> undertake action under BCP 25.
> 
> Sincerely,
> 
> Laura (for the chairs)
> 
> > On 27 Mar 2023, at 17:04, 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 

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

[Laura Atkins]

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.  This is not acceptable, 
and you have been warned before.  I contacted you off-list on behalf of the 
chairs, under the procedures in BCP 25, but you have refused to take what we 
regard as rectifying action.

Accordingly, please understand this message as a formal warning under the 
procedures of BCP 25 that, if we observe continued behaviour of the sort you 
have exhibited, we shall suspend your posting privileges to the dkim-ietf 
mailing list for 30 days.  Behaviour of the sort includes anything that we 
believe to be needlessly personalized, and especially includes _ad hominem_ 
forms of argument.  We will also treat returning to points that have been 
closed without raising new arguments as attempts to disrput the functioning of 
the Working Group.

We will act without further warning in such an event.

If we take that action, and, after restoration of your privileges, we observe 
you to return to disrupting the work of the group, we shall
undertake action under BCP 25.

Sincerely,

Laura (for the chairs)





> On 27 Mar 2023, at 17:04, 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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[Hector Santos]

> 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 for (3) along with other discussion of what was also considered and 
> rejected. For (4) it gives a basis of what not to suggest.
> 
Michael,  first, I want to express my thanks and support your stance.

Thank you for expressing the thoughts of the silent majority. I have been 
IETF-style silenced here because of my strong DKIM Policy model position.  It 
has never changed.  And history only continues to prove my concerns correct.

The DKIM and Reputation modeling has been long dreamed, but to this day - we 
have nada.  

The closest thing we have us VBR, It make an Author Domain (ADID) and SDID 
(Signer Domain) association.  So does ATPS.

Since MARID, it has been about associations of two or more identities.

With SPF, an LMAP concept, it was an Return-Path Domain::IP association.

With ADSP is was an Author Domain (ADID) and Signer Domain (SDID) association 
but we could  only work out the 1st party association with ADID equal SDID.  
This is DMARC.

With ATPS, it proposed an 1st party ADID and 3rd party SDID association.  We 
can add this to DMARC.

But someone said it does not scale and we stopped  They said Reputation is 
better!!  No Dependency on ADID!  We have nothing since 2005!!!

—
Has


___
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

[Hector Santos]

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


My understanding so far is this an ESP “Email Service Provider” only issue or a 
domain that allows for free sign-ups for email services using their domains. An 
ESP , i.e. example.esp, can be any size, high or low scale, it allows free 
sign-up service.

My understanding so far is the exploitation are free sign-up accounts using the 
domain to create a template message to some spammer box where the example.esp 
is signing the bound message.  The spammer then massages the message without 
damaging the signature and attacks downlink receivers who accepts the signer 
and/or always trust the example.esp domain.  The presumption is (imo erroneous) 
the receivers are using the same DKIM Reputation Lookup Server that example.esp 
is a member of and that these receivers are using the SDID (Signer Domain 
Identity) as input to a trust service there by bypassing spam security checks.

This is the classic “Batteries Required” syndrome that was predicted with the 
DKIM Reputation Model   With no standard, receivers do not have the tools so 
resolve this problem.

But ESP can do more control their users.   ESP can also make sure users can not 
create signed templates.

We can also finish the DKIM Policy Protocol and basically extend DMARC beyond 
its current limits.  A receiver can probably read a tag ‘-enabled.x’ that tell 
receivers to apply the signature expiration.

—
HLS


___
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

[Michael Thomas]

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


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.


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 for (3) along with other discussion of 
what was also considered and rejected. For (4) it gives a basis of what 
not to suggest.


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

[Murray S. Kucherawy]

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.

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.

-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

[Michael Thomas]

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 the case and is why rechartering was so 
problematic. Since M3AAWG can't figure it out with lots of inside the industry 
information, what makes anybody think the wider community would have better 
insight which is not speculative because it has been tested and known to work? 
It speaks volumes that they didn't have a solution in mind and bring it to IETF 
to vet in the wider community. That sure sounds like a research project to me.

It may indeed be a research project, but I’d rather see that happen in IETF or 
some similarly open venue rather than to have it happen in a closed forum like 
M3AAWG, which brings the risk that the proposed solution will meet the needs of 
only the large domains that are M3AAWG members, and not the small ones that 
aren’t.

The chair is now unilaterally making it clear that nobody is allowed to question the 
scope of non-working group drafts beyond wordsmithing, IETF process be damned. Consensus 
calls are not needed, apparently. "Politely", indeed.

I would have rather they actually had a proposal in hand so we could actually 
know what their agenda was. If it were on the strength of the current set of 
proposals, this wg should have never been rechartered because none of them work.


So far, I don't think anyone has any better ideas, which is why it was 
important that a non-protocol result be in scope for the WG.


Yet the input for such a result in the form of what the current state of 
art is is being shut down by the chairs. Politely, of course.


I would venture to say that most successful working groups have some 
amount of clue behind the scenes of what the solution is to whatever 
problem they intend to solve before they are spun up. That was certainly 
the case for what would become DKIM. That does not seem to be the case 
here. That reads research project writ large to me. This is a terrible 
venue for that.


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

[Scott Kitterman]

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 was so 
>>> problematic. Since M3AAWG can't figure it out with lots of inside the 
>>> industry information, what makes anybody think the wider community would 
>>> have better insight which is not speculative because it has been tested and 
>>> known to work? It speaks volumes that they didn't have a solution in mind 
>>> and bring it to IETF to vet in the wider community. That sure sounds like a 
>>> research project to me.
>> It may indeed be a research project, but I’d rather see that happen in IETF 
>> or some similarly open venue rather than to have it happen in a closed forum 
>> like M3AAWG, which brings the risk that the proposed solution will meet the 
>> needs of only the large domains that are M3AAWG members, and not the small 
>> ones that aren’t.
>
>The chair is now unilaterally making it clear that nobody is allowed to 
>question the scope of non-working group drafts beyond wordsmithing, IETF 
>process be damned. Consensus calls are not needed, apparently. "Politely", 
>indeed.
>
>I would have rather they actually had a proposal in hand so we could actually 
>know what their agenda was. If it were on the strength of the current set of 
>proposals, this wg should have never been rechartered because none of them 
>work.


So far, I don't think anyone has any better ideas, which is why it was 
important that a non-protocol result be in scope for the WG.

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

[Michael Thomas]

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 inside the industry 
information, what makes anybody think the wider community would have better 
insight which is not speculative because it has been tested and known to work? 
It speaks volumes that they didn't have a solution in mind and bring it to IETF 
to vet in the wider community. That sure sounds like a research project to me.

It may indeed be a research project, but I’d rather see that happen in IETF or 
some similarly open venue rather than to have it happen in a closed forum like 
M3AAWG, which brings the risk that the proposed solution will meet the needs of 
only the large domains that are M3AAWG members, and not the small ones that 
aren’t.


The chair is now unilaterally making it clear that nobody is allowed to 
question the scope of non-working group drafts beyond wordsmithing, IETF 
process be damned. Consensus calls are not needed, apparently. 
"Politely", indeed.


I would have rather they actually had a proposal in hand so we could 
actually know what their agenda was. If it were on the strength of the 
current set of proposals, this wg should have never been rechartered 
because none of them work.


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

[Michael Thomas]

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, rather than staring 
yet a different thread.


Neither have been adopted as working group items. Why should I? And my 
comments apply to them equally.


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

[Laura Atkins]

+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 Thomas  wrote:
>> 
>> 
>> 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 protocol solution and that a BCP is the only possible positive
>> outcome of this rechartering. An outcome that is specifically allowed
>> for in the charter I will note. It need not be exhaustive, but it would
>> be good to document some of the constraints on the solution space as
>> well as what has been tried and failed. x= is a perfect example.
>> 
>> Also: there has not been any consensus that the shape and scope of the
>> two current proposals is correct or sufficient. We are far from the
>> point that this is just wordsmithing imo, appeals to the contrary not
>> withstanding.
>> 
>> 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 makes anybody think the wider community
>> would have better insight which is not speculative because it has been
>> tested and known to work? It speaks volumes that they didn't have a
>> solution in mind and bring it to IETF to vet in the wider community.
>> That sure sounds like a research project to me.
>> 
>> 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

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

[Laura Atkins]

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. 

laura 



> On 24 Mar 2023, at 23:57, Michael Thomas  wrote:
> 
> 
> 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 protocol 
> solution and that a BCP is the only possible positive outcome of this 
> rechartering. An outcome that is specifically allowed for in the charter I 
> will note. It need not be exhaustive, but it would be good to document some 
> of the constraints on the solution space as well as what has been tried and 
> failed. x= is a perfect example.
> 
> Also: there has not been any consensus that the shape and scope of the two 
> current proposals is correct or sufficient. We are far from the point that 
> this is just wordsmithing imo, appeals to the contrary not withstanding.
> 
> 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 makes anybody think the wider community would have 
> better insight which is not speculative because it has been tested and known 
> to work? It speaks volumes that they didn't have a solution in mind and bring 
> it to IETF to vet in the wider community. That sure sounds like a research 
> project to me.
> 
> Mike
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Jim Fenton]

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 makes anybody think the wider community would have 
> better insight which is not speculative because it has been tested and known 
> to work? It speaks volumes that they didn't have a solution in mind and bring 
> it to IETF to vet in the wider community. That sure sounds like a research 
> project to me.

It may indeed be a research project, but I’d rather see that happen in IETF or 
some similarly open venue rather than to have it happen in a closed forum like 
M3AAWG, which brings the risk that the proposed solution will meet the needs of 
only the large domains that are M3AAWG members, and not the small ones that 
aren’t.

-Jim

___
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

[Michael Thomas]

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 
that we should do a problem statement, I wasn't expecting it to be a 
bare rehash of what's already in the charter. The current drafts are 
barely more than what's in the charter.


But as I said, we either get this out in the open now, or we'll have to 
get it in the open later. Putting it into the problem statement makes it 
easy to document the failure later instead of adding it to the confusion 
of whether anything can be done. That is, do the fact finding upfront.


Mike



Barry

On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas  wrote:


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 protocol solution and that a BCP is the only possible positive
outcome of this rechartering. An outcome that is specifically allowed
for in the charter I will note. It need not be exhaustive, but it would
be good to document some of the constraints on the solution space as
well as what has been tried and failed. x= is a perfect example.

Also: there has not been any consensus that the shape and scope of the
two current proposals is correct or sufficient. We are far from the
point that this is just wordsmithing imo, appeals to the contrary not
withstanding.

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 makes anybody think the wider community
would have better insight which is not speculative because it has been
tested and known to work? It speaks volumes that they didn't have a
solution in mind and bring it to IETF to vet in the wider community.
That sure sounds like a research project to me.

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

[Barry Leiba]

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 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 protocol solution and that a BCP is the only possible positive
> outcome of this rechartering. An outcome that is specifically allowed
> for in the charter I will note. It need not be exhaustive, but it would
> be good to document some of the constraints on the solution space as
> well as what has been tried and failed. x= is a perfect example.
>
> Also: there has not been any consensus that the shape and scope of the
> two current proposals is correct or sufficient. We are far from the
> point that this is just wordsmithing imo, appeals to the contrary not
> withstanding.
>
> 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 makes anybody think the wider community
> would have better insight which is not speculative because it has been
> tested and known to work? It speaks volumes that they didn't have a
> solution in mind and bring it to IETF to vet in the wider community.
> That sure sounds like a research project to me.
>
> 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

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

[Michael Thomas]

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 protocol solution and that a BCP is the only possible positive 
outcome of this rechartering. An outcome that is specifically allowed 
for in the charter I will note. It need not be exhaustive, but it would 
be good to document some of the constraints on the solution space as 
well as what has been tried and failed. x= is a perfect example.


Also: there has not been any consensus that the shape and scope of the 
two current proposals is correct or sufficient. We are far from the 
point that this is just wordsmithing imo, appeals to the contrary not 
withstanding.


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 makes anybody think the wider community 
would have better insight which is not speculative because it has been 
tested and known to work? It speaks volumes that they didn't have a 
solution in mind and bring it to IETF to vet in the wider community. 
That sure sounds like a research project to me.


Mike

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