Re: Remote participants, registration, and mailing lists -- unintended consequences

Dave Crocker <> Sun, 03 April 2016 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A552E12D104; Sun, 3 Apr 2016 09:56:55 -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 autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XgJm2shE70V5; Sun, 3 Apr 2016 09:56:54 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 449D812D102; Sun, 3 Apr 2016 09:56:54 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u33Gurrm031637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 3 Apr 2016 09:56:53 -0700
Subject: Re: Remote participants, registration, and mailing lists -- unintended consequences
References: <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sun, 3 Apr 2016 09:56:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 03 Apr 2016 09:56:53 -0700 (PDT)
Archived-At: <>
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 16:56:55 -0000

On 4/3/2016 8:29 AM, John C Klensin wrote:
> So, for the future, if we are really going to do this remote
> participant registration thing, it would be nice if someone
> would really take responsibility for thinking through all of the
> implications and take action on them.

The complexities and subtleties of this task are significant.

I suggest creating a wiki page for collaboratively developing a list og 
issues, requirements, preferences, fears, etc.  We can add to it (or 
delete from it) as we gain experience.  This will be a long process. 
Eventually the page might get relatively stable, but I suspect only 

An obscure example of the challenge:  Being able to see the posters that 
are put up for viewing during the social, since remote attendees aren't 
at the social.  But the posters are worth reviewing.

The rather daunting meta-issue is learning to think and plan for IETF 
Meeting details much as the universal access folks have had to train 
architects to think:  At every decision-point, think about the decision 
in terms of remote attendees and make explicit functionality and 
usability decisions about them.  (Obviously deciding not to accommodate 
remote attendees can be an entirely justifiable choice, depending on the 


   Dave Crocker
   Brandenburg InternetWorking