Re: Planned changes to registration payments & deadlines

John C Klensin <john-ietf@jck.com> Thu, 26 April 2018 13:03 UTC

Return-Path: <john-ietf@jck.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 A5B5D1201F2 for <ietf@ietfa.amsl.com>; Thu, 26 Apr 2018 06:03:55 -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] autolearn=ham autolearn_force=no
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 njfSjWskgzHh for <ietf@ietfa.amsl.com>; Thu, 26 Apr 2018 06:03:49 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E101243F6 for <ietf@ietf.org>; Thu, 26 Apr 2018 06:03:49 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fBgYs-0007rR-7M; Thu, 26 Apr 2018 09:03:46 -0400
Date: Thu, 26 Apr 2018 09:03:38 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: Andrew Sullivan <ajs@anvilwalrusden.com>, ietf@ietf.org
Subject: Re: Planned changes to registration payments & deadlines
Message-ID: <F9C9AF4402D59BE5351B1BB9@PSB>
In-Reply-To: <bb921f4d-138d-1e88-bacf-3bca2601e626@gmail.com>
References: <20180419174627.2krzjbxgx25s5wxz@mx4.yitter.info> <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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hTTEmhhLqQJN5wgdoKRwNhfcrTM>
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 13:03:55 -0000


--On Thursday, April 26, 2018 15:57 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> 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."
> 
> 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.
> And people who don't make the 7 week deadline will then delay
> until the 2 week deadline. So the side event organiser 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.)
> 
> I'm not saying that's a disaster. But it is a change not
> mentioned in your initial posting.

Remembering that we used to go to considerable lengths to
prohibit or inhibit "side events" as a distraction from the
IETF's work and that many of the "side events" that occur today
cause at least some work for the Secretariat and increase the
demands we place on facilities, let me make a counterproposal.
This is made more to try to bring the issues that are being
raised into focus than as a real proposal but, if the IAOC
wanted to consider it, I wouldn't lose any sleep over the idea.

We redefine things so that there are two kinds of side events.
Type 2 is the "old" variety: no use of IETF facilities, even
announcements on bulletin boards, no coordination with the
Secretariat, use of the meeting hotel (or venue if different)
strongly discouraged or, if it occurs, forcing event organizers
to make their own arrangements with the venue with no allowances
for adjustments for co-location with the IETF.  What the IETF
does about registration has no effect on this type of event
because there just is no interaction.

Type 1 involves the kind of coordination that I infer from
Brian's message but anyone applying to set up such a side
meeting, asking the Secretariat for room or scheduling
assistance, or wanting to make arrangements with a venue or
hotel on the coattails of IETF contracts initiates those actions
with an application to IAOC or AMS that is accompanied by a fee
of several times the "standards" registration fee. A few "side
event" applications at 5 or 10K USD each in addition to
registration fees for those attending would, presumably, justify
the costs of giving out preliminary registration numbers to
people making notices of intent to attend.  If the IAOC wer4 to
make a nominal charge for such notices (as a deposit to be
credited against the registration fee when paid), it might also
help... and, in combination with the rest, have a noticeable
benefit to the bottom line.

Again, mostly just a thought to clarify the issues and one that
should probably come with a disclaimer than I've never liked the
idea of side meetings (or highly organized pseudo-BOFs or
pseudo-bar-BOFs that require space but don't go through the
normal review, approval, and agenda processes and the
expectation of minutes) so I'd consider making them harder a
benefit.  But, if we are going to complain (or even notice) that
changes in registration models inconvenience side meetings or
their organizers, we should also be considering the incremental
costs of such meetings and probably discussing how to recover
those costs (and whether it makes sense to make money on them).

best,
   john