[Ietf-dkim] Cooling things off

[Murray S. Kucherawy]

Colleagues,

Things have gotten somewhat heated in here.  I think we need to take a step
back.

While I have no doubts whatsoever that the participants and chairs are
well-intentioned and would like to see this working group make progress in
an appropriate direction, even if we may not all agree yet on what that
direction is, it is critical to follow process and, more importantly, to
behave in a respectful and professional manner.

The IETF's Code of Conduct can be found in BCP 54 (RFC 7154).  If you have
not read it, please take the time to do so.  As with the IPR rules of the
IETF, everyone on this list is expected to observe those guidelines, and
consistently straying from them makes you eligible for corrective handling
under BCP 25.

To be clear, I have no concerns with questions about proper procedure.
Questions are welcome.  I need reminders of proper process from time to
time.  Also, a procedural error does not constitute evidence of malice.
Any public challenges to authority or procedural decisions must be
delivered respectfully and professionally.  If you can't, or won't, then do
it privately.

Laura is a new chair and is still learning our processes.  I would like to
thank her for taking on this work in any working group, especially this
one.  Development of new talent in the IETF is to be supported, and I
intend to do so.  Tim and I are providing support, but this week has been
challenging as we're spread very thin during IETF 116.  This has been
baptism by fire for her.  I would appreciate it if people provided her with
guidance when we aren't able to do so.  I want to make clear that openly
assaulting her integrity as she undergoes this onboarding will not be
tolerated.

As any of us, the chairs are allowed missteps, especially while learning,
so I would like to help here by correcting two of them.  Also, as
mentioned, we need to cool off.  Thus, effective immediately:

(1) The action under BCP 25 (RFC 3934) regarding Michael Thomas is reversed
by one step; the "communicating privately" step has been completed, but the
public warning is struck.

(2) The chairs should initiate a Call For Adoption of a reasonable period
on one of the problem statement drafts.  The working group is reminded that
adopting a draft does not endorse its content as final or even close to
final; it's merely a starting point for discussion and iteration.  The
chairs may select one of the candidate documents at their discretion.

(3) The working group's list is to be set for moderation until next week to
provide a cooling off period.  Working group business may still be
conducted, but the chairs will review posts to ensure they are moving the
WG's purposes forward, and comply with BCP 54, before approving them.
Anything else will be rejected.

-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

[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] On the current state of DKIM and the replay problem

[Michael Thomas]

On 3/28/23 11:07 AM, Hector Santos wrote:

On Mar 28, 2023, at 1:36 PM, Michael Thomas  wrote:

Since the chair is threatening to ban me, I decided to write up my view of 
things in a longer form.

https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html

This has some technical aspects and meta aspects. The meta aspects can be 
addressed in the blog comments itself instead of here.

Mike


Lol.

“I, for one, welcome/our/new computer/overlords/”.

Mike


Mike,

I asked ChatGPT 4.0 to summarize your extensive blog post for me.

Summary:

The blog post discusses concerns related to DMARC, ARC, and DKIM Replays in the 
context of email security and the working group's efforts to address these 
issues. The author expresses confusion and skepticism about the necessity and 
effectiveness of the proposed solutions.

Top concerns and conflicts:

1. Unclear motivations and politics behind DMARC: The author questions the 
reasons behind DMARC's creation and its differences from ADSP, as well as the 
intentions of the working group members involved.

2. ARC's purpose and necessity: The author doubts the need for ARC, which 
recreates DKIM and Authentication-Results with minor tweaks, and its ability to 
solve mailing list traversal problems.

3. DKIM Replay problem and lack of clear solutions: The blog post raises 
concerns about the lack of consensus on how to address the issue of DKIM 
Replays, as well as the opacity of mailbox providers' practices.

4. Insufficient information and secrecy: The author argues that the lack of 
transparency from mailbox providers and the closed nature of industry groups 
like M3AAWG hinder the working group's ability to develop effective solutions.

5. Ineffective proposed solutions: The blog post criticizes the solutions 
proposed so far, arguing that they do not seem practical or likely to
work.

6. Unclear definition of success: The author points out that there is no clear 
goal for the working group to achieve, as the spam issue is not a matter of 
absolutes but rather probabilities.

7. Passive-aggressive working group chairs: The author criticizes the behavior 
of the working group chairs, suggesting that they may have
their own agendas or be uninterested in finding solutions.

8. Doubtful effectiveness of the rechartered working group: The author believes 
that the working group's track record, combined with the lack
of available tools and knowledge within the IETF community, makes success 
unlikely.


—
HLS


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

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

[Hector Santos]

> On Mar 28, 2023, at 1:36 PM, Michael Thomas  wrote:
> 
> Since the chair is threatening to ban me, I decided to write up my view of 
> things in a longer form.
> 
> https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html
> 
> This has some technical aspects and meta aspects. The meta aspects can be 
> addressed in the blog comments itself instead of here.
> 
> Mike

Mike, 

I asked ChatGPT 4.0 to summarize your extensive blog post for me.

Summary:

The blog post discusses concerns related to DMARC, ARC, and DKIM Replays in the 
context of email security and the working group's efforts to address these 
issues. The author expresses confusion and skepticism about the necessity and 
effectiveness of the proposed solutions.

Top concerns and conflicts:

1. Unclear motivations and politics behind DMARC: The author questions the 
reasons behind DMARC's creation and its differences from ADSP, as well as the 
intentions of the working group members involved.

2. ARC's purpose and necessity: The author doubts the need for ARC, which 
recreates DKIM and Authentication-Results with minor tweaks, and its ability to 
solve mailing list traversal problems.

3. DKIM Replay problem and lack of clear solutions: The blog post raises 
concerns about the lack of consensus on how to address the issue of DKIM 
Replays, as well as the opacity of mailbox providers' practices.

4. Insufficient information and secrecy: The author argues that the lack of 
transparency from mailbox providers and the closed nature of industry groups 
like M3AAWG hinder the working group's ability to develop effective solutions.

5. Ineffective proposed solutions: The blog post criticizes the solutions 
proposed so far, arguing that they do not seem practical or likely to
work.

6. Unclear definition of success: The author points out that there is no clear 
goal for the working group to achieve, as the spam issue is not a matter of 
absolutes but rather probabilities.

7. Passive-aggressive working group chairs: The author criticizes the behavior 
of the working group chairs, suggesting that they may have
their own agendas or be uninterested in finding solutions.

8. Doubtful effectiveness of the rechartered working group: The author believes 
that the working group's track record, combined with the lack
of available tools and knowledge within the IETF community, makes success 
unlikely.


—
HLS



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

[Ietf-dkim] On the current state of DKIM and the replay problem

[Michael Thomas]

Since the chair is threatening to ban me, I decided to write up my view 
of things in a longer form.


https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html

This has some technical aspects and meta aspects. The meta aspects can 
be addressed in the blog comments itself instead of here.


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