Remote participation in IAB workshops

"Joe Hildebrand (jhildebr)" <> Sun, 03 April 2016 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 125AC12D1A3; Sun, 3 Apr 2016 05:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HLvzgGTVUVpU; Sun, 3 Apr 2016 05:58:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C96F12D535; Sun, 3 Apr 2016 05:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6254; q=dns/txt; s=iport; t=1459688290; x=1460897890; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=V+ZZBkSJSLFdi3/jxLVzGEVarplcCLpMwcQtsRAaQGY=; b=OAUKop5S8k4QcUk8tEgOEfw2TeAtMe2Oer/K+UNiDgaR1cH/IZbvNQBy E/EJUL+4CLjH+6rnoGPuE5tHJtxpOeaOtK4Dh5AknYaw4Ix9bNK4TctOs Oaf6cTz3N+h7RdhmUMZzIlOGtAijUY2UDEyUuGsJGX2+d5qqR6yIu5rWb U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.24,436,1454976000"; d="scan'208";a="256017884"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2016 12:58:09 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u33Cw9xW006009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2016 12:58:09 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Apr 2016 08:58:08 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Sun, 3 Apr 2016 08:58:08 -0400
From: "Joe Hildebrand (jhildebr)" <>
To: "" <>, "" <>
Subject: Remote participation in IAB workshops
Thread-Topic: Remote participation in IAB workshops
Thread-Index: AQHRjah4kcLD23/qI0CAnNsEkCbc7w==
Date: Sun, 03 Apr 2016 12:58:08 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: IAB <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Apr 2016 12:58:13 -0000

The IAB has heard from the community a desire for more openness in our workshops, including remote access.  After a good amount of discussion, we continue to believe that for IAB workshops, there are sometimes good reasons not to default to the IETF's usual stance of full realtime remote access for anyone that wants to participate.  Our practice will continue to be to allow the Program Committee (PC) for a given workshop to decide how best to include the community in order to accomplish the technical goals of a given workshop.

We are updating our internal documentation on how to run a workshop with tradeoffs for the PC to consider, particularly around how open to make the discussion.  Here are some of those considerations, for community comment:

Keeping in mind that an IAB workshop is often held at the very beginning of our community's discussion of a given topic, it is sometimes important for the discussion to be as unencumbered as possible by Audio/Visual overhead (Stand There! Speak into the mic! Say your name!) in order to get to the heart of an
architectural discussion in the short time we have for the workshop.  Allowing full remote participation (Jabber relay! Mute your line!) would cause even more impact to the in-room discussion, with today's typical technology.

For some workshops, at least a portion of the discussion is held using the Chatham House Rule (, in an attempt to elicit input that participants would not be able to offer in a session where all input is attributed.  In those cases, remote participants would need to accept the Rule explicitly, or be dropped for that portion of the conversation.  With remote participants, Chatham House Rule contributions can be more difficult to elicit because it is more difficult to build the personal trust required.  The use of the Chatham House Rule *has* been useful in several previous workshops.

For many workshops, a voice or video recording is made to assist in later preparation of notes.  Recording devices are stopped during any portion of the discussion the happens under the Chatham House Rule, in order to help shield the anonymity of the participants in those discussions.

For some workshops, individual invited remote contributors might be accommodated.  This approach can avoid *some* of the previous issues by training the remote participant ahead of the meeting (check hardware, ensure they are always on mute unless speaking, etc), and ensuring that the remote participant has explicitly agreed to whatever operating rules are chosen by that workshop.  Such invitations are at the discretion of the PC, and will be balanced between the usefulness of the remote contribution and the cost/complexity/discussion overhead created.

For all workshops, the PC will strive to make raw minutes available as quickly as possible after the workshop.  For several of the of the recent workshops, transcripts have been available within a week or so.  The IAB-stream RFC with the full workshop report of course takes longer to prepare, analyze, and approve.

The PC will therefore need to decide the value of getting the larger community information in near real time vs waiting a week or so for transcripts.  If they decide more remote participation is desired, they will have to budget appropriately for equipment, web meeting services, technicians, etc.

In the case of the MaRNEW workshop, the PC decided that we wanted a robust in-person discussion with a portion being under the Chatham House Rule.  We further committed to getting minutes published as quickly as possible (here:  As such, we decided that remote participation was not a priority for this workshop.

In the case of the IOTSI workshop, the purpose was to get participants from many SDOs and organizations with different IPR rules.  (Indeed, as discussed at the IETF 92 tech plenary, the IoT semantic interoperability problem is largely outside the scope of the IETF.)  As such, the PC decided that the IETF Note Well would be inappropriate, and that it would be up to the participants whether Chatham House rules would apply.  Therefore, the PC decided that remote participation was not a priority for this workshop.

If you would like to discuss this further in public, please use (subscribe at  Confidential notes can be sent to the IAB at

Joe Hildebrand
On behalf of the IAB