Re: Planned changes to registration payments & deadlines

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 26 April 2018 04:35 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361D127867 for <ietf@ietfa.amsl.com>; Wed, 25 Apr 2018 21:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=IXrER6zx; dkim=pass (1024-bit key) header.d=yitter.info header.b=VkrExQ/c
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0KbvXCGTPRd for <ietf@ietfa.amsl.com>; Wed, 25 Apr 2018 21:35:14 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505D012426E for <ietf@ietf.org>; Wed, 25 Apr 2018 21:35:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 756A2BF280 for <ietf@ietf.org>; Thu, 26 Apr 2018 04:35:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1524717313; bh=W+c2d+TrC3/8pRuCqgJMmrMXby627zpySEdcUGTq7cA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=IXrER6zx+Kdcbgl8DRv6htI49bU8stlFcUaZrentspPt3J4vG0NIua8b+sInYEc/f F6+LNaMVKlvloYy7kKE/shZJtyY922kuuSkb9tg53bs5yuFv5ybQccjP87qlkkc1I0 SlYfh6kPzCwKZ+mfH2gNN5DiFF77TK3TTXDADqMM=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnSKws-sIl7y for <ietf@ietf.org>; Thu, 26 Apr 2018 04:35:12 +0000 (UTC)
Date: Thu, 26 Apr 2018 00:35:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1524717312; bh=W+c2d+TrC3/8pRuCqgJMmrMXby627zpySEdcUGTq7cA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=VkrExQ/cHRVyh9UO9Af738CMNgmCFmafU13NU8hMqfgc2KGpyNmPS1OzRbkIPw3Z8 nXFrMbm7LmRbJx7l6VlE7q8U4AgNTqH2JS9hOma0MZ6KHRQE2rkREHT9weRsrWo183 z5foB5dszURsNgB9oVhv98RfqO306+LqDzhS6hiI=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ietf@ietf.org
Subject: Re: Planned changes to registration payments & deadlines
Message-ID: <20180426043508.nr6tgmosynwo7djc@mx4.yitter.info>
References: <20180423162016.elmju5r6qcb6xcbt@anvilwalrusden.com> <6E58094ECC8D8344914996DAD28F1CCD8779EC@DGGEMM506-MBX.china.huawei.com> <20180424141306.zb5kefcac3b633az@mx4.yitter.info> <074F424E-F757-41CA-83E1-54BAF741E24C@vidyo.com> <20180424165612.ecmdyay5ftfajfv3@mx4.yitter.info> <453ab53b-6368-1397-db5b-7f8988a413b1@gmail.com> <162fa738af8.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <dce584d0-e3ae-b369-314c-87a667679fa3@cs.tcd.ie> <20180425120624.abei3nltmpzj2hgy@mx4.yitter.info> <bb921f4d-138d-1e88-bacf-3bca2601e626@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <bb921f4d-138d-1e88-bacf-3bca2601e626@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EJCK686mXSHddZzyYxbPWHC3FDk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2018 04:35:16 -0000

Hi,

On Thu, Apr 26, 2018 at 03:57:50PM +1200, Brian E Carpenter wrote:
> Let me just adjust your text to make it more precise:
> 
> "If you could register for ancillary things without having *paid* for the
> meeting, then if you never *pay* we'd need to have tracked those
> other things and be able to undo them."

That's not "more precise"; that's just a different meaning of
"registered."

I confess that I have never understood the IETF meaning of
"registered", in which one could be in this half-state of registered
for the meeting but not paid.  I've never been to any other
paid-attendance thing where there was any way to be publicly
registered without paying first.  But it is true, as I think we have
said all along in this discussion, that we are changing the meaning of
"registered" to mean "paid registration".  The plan does not
anticipate any other meaning of "registration".
 
> Correct, and I fully understand that. But a side effect of the change
> is that anybody currently using the registration system as a convenience
> for arranging a side event can effectively no longer do so until the
> 7 week deadline, because people *will* pay at the last possible moment
> to minimise their credit hit.

I guess I don't understand the complaint.  To the same extent that the
IETF has a hard time predicting whether people will really show up
without knowing whether they've paid, anyone else would not know
whether the prospective attendee was really coming.  And presumably
the entire list of IETF attendees wouldn't be going to the side event,
so the list is too broad anyway.  Finally, the list is collected for
the purposes of registration for the IETF meeting and not some other
event, so actually using the data for some other purpose might be in
contravention of EU laws (alas, I am not a lawyer, so I can't say for
certain).  It seems such a side event would be better off maintaining
an independent list of prospective attendees.

> won't get attendance mainly settled until the last 2 weeks. They will
> see two large spikes in registration corresponding to the two payment
> deadlines. (So will IASA, of course.)

Maybe we (and it's not _IASA_, but the IETF, of course) will see that
and maybe we will not.  It is hard to know without trying it.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com