Re: [93attendees] Network experiment during the meeting

Dave Crocker <> Wed, 15 July 2015 14:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 72FFF1ACAD8 for <>; Wed, 15 Jul 2015 07:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6yTAKmltBp2R for <>; Wed, 15 Jul 2015 07:57:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4720A1AC7E7 for <>; Wed, 15 Jul 2015 07:57:10 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6FEv41X013256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jul 2015 07:57:09 -0700
Message-ID: <>
Date: Wed, 15 Jul 2015 07:56:59 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Jared Mauch <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 15 Jul 2015 07:57:09 -0700 (PDT)
Archived-At: <>
Cc: "" <>
Subject: Re: [93attendees] Network experiment during the meeting
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list of IETF 93 attendees that have opted in on this list. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jul 2015 14:57:11 -0000

On 7/15/2015 6:59 AM, Jared Mauch wrote:
> 	I'm not saying there may be regulatory regimes where the legal
> situation may be different than what I outlined above, but the easiest
> way to not be part of this is to opt out by not using the IETF
> network.  Seems like a fairly affirmative way.  It's interesting how
> IETF went from being engineering based to lawyer based.

That view requires some assumptions, such as:

   1.  Everyone in the room will be sufficiently well-informed and in a
sufficiently timely manner, to be able to know opt-out.  It means, for
example, that even someone who is not on this list and who arrives late
to the session, we have some way of knowing to opt-out.  I don't know
how you are going to achieve that level of pervasive knowledge, and
mostly I suspect it is not possible.

   2.  Placing the burden on each user of opting out is reasonable.  It
presumes, for example, that those running the network and/or conducting
the experiment do not have an affirmative obligation to gain explicit
user permission beforehand.  (This issue about proper requirements for
gaining permission is a classic source of tension between marketers and
anti-spam practitioners.)

   3.  Being deprived of network access during a plenary is a reasonable
burden to place of attendees who opt-out

> 	The adage about how many people it takes to build something
> vs tear it down seems like it may be applicable here and private
> *constructive* input to the parties involved would have a positive
> response.

The activity was announced not as a possibility, soliciting comments,
but as certain to happen.  There was no indication that basic questions
of privacy and user agreement had been considered.  And there isn't all
that much time left.

So, sorry, but raising concerns about this publicly is what was needed.
 It also provided a way of determining whether the IETF community cares
about the privacy and user agreement issues for this activity.

Dave Crocker
Brandenburg InternetWorking