Re: IETF in July

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 26 March 2020 02:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0D2663A0863 for <ietf@ietfa.amsl.com>; Wed, 25 Mar 2020 19:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 1SgV95Lwv8nX for <ietf@ietfa.amsl.com>; Wed, 25 Mar 2020 19:03:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACB03A087D for <ietf@ietf.org>; Wed, 25 Mar 2020 19:03:27 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C95D538982 for <ietf@ietf.org>; Wed, 25 Mar 2020 22:02:01 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6D2B6547 for <ietf@ietf.org>; Wed, 25 Mar 2020 22:03:26 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF discussion list <ietf@ietf.org>
Subject: Re: IETF in July
In-Reply-To: <39E48ABD-B04A-4855-AB5D-566EFF85691C@episteme.net>
References: <DM6PR05MB63488A5D5D14D11CBF145CEBAEF50@DM6PR05MB6348.namprd05.prod.outlook.com> <2E3DFE67-85D0-4259-85D5-09FF9A262B48@tzi.org> <B28C7981-1AF4-4299-AAA0-4ABA667D81B4@consulintel.es> <CAOj+MMHROy2UA7YUdRrTM240nQY4ykbYHtFME87FPznNDMdcUQ@mail.gmail.com> <0B0BBC48-1504-4847-85B1-36700873D78E@consulintel.es> <5134FD38-F675-4E81-8C57-1EBCBE475705@tzi.org> <1966.1585066127@localhost> <9C4D87CA-784C-4AC0-8F36-2699D74E837E@live555.com> <39E48ABD-B04A-4855-AB5D-566EFF85691C@episteme.net>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 25 Mar 2020 22:03:26 -0400
Message-ID: <31089.1585188206@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Yq18O6CmvcBwbwxTdIGGN6QVnYY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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 Mar 2020 02:03:30 -0000

Pete Resnick <resnick@episteme.net> wrote:
    >>> But, I agree that making IETF108 virtual is probably best.
    >>>
    >>> What I'd like to see is that we agree
    >>> 1) that the Madrid Time Zone will be used for all plenary stuff
    >>
    >> Why?  If IETF 108 becomes virtual, then there’ll be no relationship with
    >> Madrid at all.
    >>
    >> As with the current, ongoing virtual IETF 107 (which has no relationship
    >> with Vancouver), just choose a time zone that (tries to) work best for the
    >> worldwide IETF community.

    > The schedule for 107 maps pretty well to the Vancouver time zone. I think a
    > reason one might choose Madrid as the time zone for 108 if we have to go
    > virtual fits pretty well with the intention of RFC 8719:

    > [The North America / Asia / Europe] meeting
    > rotation is mainly aimed at distributing the travel effort for the
    > existing IETF participants who physically attend meetings and for
    > distributing the timezone difficulty for those who participate
    > remotely.

Exactly. I didn't think to quote 8719, but it captures my intent exactly.

We are willing to travel and adjust our internal clock, so we should continue
to do this, as it shares the benefits.

How many remote attendees did not come from +0800 (China, parts of Australia, etc.)
and +0900/+1000 (NZ, I think) to the plenary because it was at 0-dark-oclock?
(If we we go with Bangkok day time for 109, California night-owls might not
even notice, once they figure out that Wednesday occurs on Tuesday evening)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-