Re: [secdir] Secdir review of draft-moonesamy-ietf-conduct-3184bis

S Moonesamy <sm+ietf@elandsys.com> Fri, 15 November 2013 08:26 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4A21F9A59; Fri, 15 Nov 2013 00:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.185
X-Spam-Level:
X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaqGzQkLzQBK; Fri, 15 Nov 2013 00:26:25 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8038E11E8106; Fri, 15 Nov 2013 00:26:24 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.143.151]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAF8PwUb009498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 00:26:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384503974; bh=wt1jOy4+ApxDpy6ZHcQoy60FcEPopExSeA65V8N2/cE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=haV0frKuC0eERv7P+xf5XtUKMAKi82P96dwkSS37mm8v8qcAs8WSfLau6q+ilnhLC PgYIGUpw5O2QT1O0JEXwBs/FHoXjaYmsvNpD+Vk15EOLeuRzzGMMqHYPpYZC8EeVdw RKP7YBCEFQ+JOeJ4A8XxXFA7hfkzzyMNT1YcNugA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1384503974; i=@elandsys.com; bh=wt1jOy4+ApxDpy6ZHcQoy60FcEPopExSeA65V8N2/cE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yzEdcB79H7ZRePHxG4d4wcpKhTafaJYnwRYOI0gcCIg58D/TzrLNnHTT9JjH4wrze 4I1g98x0vzgJvH+eouuWSMYgyyt+atR7SvfG0a6cHfPhO8/DT7YeLEYVKW5qnM9i+2 y1YRiZuF6/b3SpnpJ2X4sGxbwqOprSWGHYHemBOg=
Message-Id: <6.2.5.6.2.20131114210001.06d56f78@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 15 Nov 2013 00:10:50 -0800
To: Alan DeKok <aland@deployingradius.com>, secdir@ietf.org, draft-moonesamy-ietf-conduct-3184bis.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <5284FBA2.3000404@deployingradius.com>
References: <5284FBA2.3000404@deployingradius.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Ines Robles <mariainesrobles@googlemail.com>, ietf@ietf.org
Subject: Re: [secdir] Secdir review of draft-moonesamy-ietf-conduct-3184bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 08:26:28 -0000

Hi Alan,
At 08:34 14-11-2013, Alan DeKok wrote:
>   I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  These comments were written primarily for the benefit of the
>security area directors.  Document editors and WG chairs should treat
>these comments just like any other last call comments.
>
>   This document provides a set of guidelines for personal interaction at
>the IETF.  This review therefore ignores any computer protocol issues or
>attacks, and focuses on personal and procedural attacks.
>
>...
>2. Principles of Conduct
>
>    1. IETF participants extend respect and courtesy to their colleagues
>       at all times.
>
>   This is a lofty goal, especially considering the next sentence:
>
>      IETF participants come from diverse origins and backgrounds and
>      are equipped with multiple capabilities and ideals.
>
>   I would suggest adding "expectations and assumptions" to that
>sentence.  Very often, misunderstandings come from differing
>expectations.  Two participants might believe they share a language.
>However, underlying assumptions mean that the words have different
>meanings.  The expectations means that the approach people take is
>different.

Quoting from Section 2 of RFC 3184:

   "1. IETF participants extend respect and courtesy to their colleagues
       at all times.

       IETF participants come from diverse origins and backgrounds and
       are equipped with multiple capabilities and ideals."

I read it more of a guideline than a goal.  Please note that the 
guideline or goal has been there for over ten years and every 
participant since then agreed to follow it.

I agree that misunderstandings come from differing 
expectations.  I'll suggest the following change to the first 
sentence of the second paragraph in Section 2:

      IETF participants come from diverse origins and backgrounds; there
      can be different expectations or assumptions.  Regardless of
      these individual differences, participants treat their colleagues
      with respect as persons especially when it is difficult to agree
      with them.  Seeing from another's point of view is often revealing
      even when it fails to be compelling.


>   On a simplistic level, everyone believes that they are a reasonable
>person.  Everyone believes that other people have the same mental models
>they do.  Everyone believes that other people do (and will) behave the
>way that they do.

Agreed.

>   These assumptions are often wrong.  Discord in groups often comes from
>the misunderstanding what other people mean, and attributing
>maliciousness to what is actually differing assumptions and expectations.

Agreed.

>    2. IETF participants discuss ideas impersonally without finding fault
>       with the person proposing the idea.
>
>   It may be useful to re-phrase this as a positive statement.  i.e.:
>
>   IETF participants discuss impersonal ideas, using evidence, fact, and
>logic.  Discussions of persons, personalities, or motivations are
>outside of the scope of the IETF.

There is the following two paragraphs after the above: "try to 
provide data and facts for your standpoints".  That would cover 
evidence and fact.  I'll suggest the following text based on the 
"positive statement" comment.  I'll include the text from the 
following paragraph as there has been changes to it:

   2. IETF participants have impersonal discussions.

      We dispute ideas by using reasoned argument rather than through
      intimidation or personal attack.  Try to provide data and facts for
      your standpoints so the rest of the participants who are sitting on the
      sidelines watching the discussion can form an opinion.  The discussion
      is easier when the response to a simple question is a polite 
answer [SQPA].

>   Items (3) and (4) seem reasonable to me.
>
>   Other items which may be considered are the following.  They are less
>inter-personal behavior, than behavior of an individual interacting with
>the larger IETF.
>
>- progress.  Participants are expected to contribute to the progress of
>the working group.  Simple participation isn't enough.  We have to get
>things *done*.

Agreed.

The question I would ask is: how can Person X contribute to the 
progress of the working group?

It helps to have participants who take a critical view of the 
work.  Personally, I would not consider that as hampering 
progress.  It's difficult for an individual to determine whether he 
or she is being too insistent or not.

>- consensus.  Participants are expected to accept the consensus of the
>WG or the larger IETF.  Standards creation necessarily involves
>compromise.  Compromise doesn't mean you've been personally put down.
>It just means life is imperfect.

Yes.

There are times when a group gets into group-think.  A person might 
consider conforming to the opinions expressed by others as accepting 
the consensus even though the person considers that the group's 
decision is incorrect.

The items (see above) would fit within a discussion about both 
conduct and consensus.  It would be useful to document it in a Wiki.

>   IMHO, the Security Considerations section is not correct.
>
>    Guidelines about IETF conduct do not affect the security of the
>    Internet in any way.

The following text was suggested [1]:

   Guidelines about IETF conduct do not directly affect the security of the
   Internet.

>   A social denial of service attack can affect the security of the
>Internet.  The way to shut down progress on security solutions is simple
>and cheap.  Attack the relevant players in court with spurious
>accusations of harassment.  Sideline the group with discussion of
>politics.  Have people "pick sides", and generally devolve the group
>into endless bickering.

I agree that the above can be a problem.  RFC 3552 can be used for 
the security aspect.  The document can fix the social issues.  It is 
up to whomever is responsible to step in when there is bickering.

>   The IETF has been subject to minor attacks by people who engage in
>attacks, appeals, and who are repeatedly banned from WG participation.

Appeals are a part of the process.  I would look at the above as an 
inconvenience instead of an attack.

>If one person made it their life goal to destroy the IETF with false
>allegations, they could have a significant impact on progress.

Yes.  It's better not to give a person a reason to do that.

Thanks for the review.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf/current/msg83994.html