Re: IETF in July

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 26 March 2020 02:36 UTC

Return-Path: <brian.e.carpenter@gmail.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 A7B113A093C for <ietf@ietfa.amsl.com>; Wed, 25 Mar 2020 19:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Gs9ps63cqWzH for <ietf@ietfa.amsl.com>; Wed, 25 Mar 2020 19:36:33 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074773A080B for <ietf@ietf.org>; Wed, 25 Mar 2020 19:36:32 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id a23so1587894plm.1 for <ietf@ietf.org>; Wed, 25 Mar 2020 19:36:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7XBR0z/kH7KbidGxtFhbsuE39ymr8hx2tAScbizt1/M=; b=ASXGAnu+amx8v+ldzJ6qoGB4bOxAM6w0SCKrpFjpY3HXwvpNizN46YtsBROkaIxiS4 lBI1l08IQKuc4P9ZjmdJATwbtYvg7/Y8SHc1hNvs4QV9nP8d5R+7p0eWObCtsqjBDnq/ fpgcocKcjzbe9sjKD6n8lwTFKaY+e3SoQnLPwchZZKQEy3mjY4ebDVX7G5nt04Erv6ET JKV3au/QY0Qy8YuxsopOPBcnsFemM1OGvrk4uIs1MLS/pk1VH01EqqRMATnWyqNmyr1M z269uunpZTBo3fMpOUBQGkBSIfUSs9HHWBHgJbRqF42zyKMbK3892TFBwLBYaO54NTQx VN1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7XBR0z/kH7KbidGxtFhbsuE39ymr8hx2tAScbizt1/M=; b=d1zB18skYnfUoicHSTzlYXuflyG7LFC3DNHd2UElbZQu5zaHvbfn95TLqLqc2E8ZxB clDgPzMlljGs/bjktbaaLYf4AFAM+ex4xssSEpRBXnXFuNyqnwAc9HnE6tUoTevWuwcu Dk9kLN98ZPMJq1AGydFg5YW6kgSlHsJ8mHsDFP0IvrJfjHidgysxIFKx738Cm1+654/V 53tUpOdQwXuMsmIXzodxzvDYHUhpp0+4vmw6czSMzQ/DBXgxjskfeGfq8oIIXElB4++1 ptrGk60Yjs59KKVFYPl4I9rPWJ5+Pv1FkHa2QrHpdnmDSj93uStHDddEXoYFqRxG5+To 23Tg==
X-Gm-Message-State: ANhLgQ0Oa/lJOaF7mJ9tjorf0kfwXH9cECI2YOdXeu9JdrjnUGBMHFsO JcVHvibQ0gXlCiRI+5YwDjCmA1YN
X-Google-Smtp-Source: ADFU+vvlQ+ELZOo8/wNLiqGtVyaXaVNRtYT71JOAi3y8ozdANwfKMEwbsQ0x0AsNKmA0Rr70lLDJRg==
X-Received: by 2002:a17:90a:33d1:: with SMTP id n75mr586733pjb.167.1585190191864; Wed, 25 Mar 2020 19:36:31 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id l127sm378751pga.94.2020.03.25.19.36.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 19:36:31 -0700 (PDT)
Subject: Re: IETF in July
To: Michael Richardson <mcr+ietf@sandelman.ca>, IETF discussion list <ietf@ietf.org>
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> <31089.1585188206@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c51ca617-1f0f-aa80-4920-b40ea5fe5e7e@gmail.com>
Date: Thu, 26 Mar 2020 15:36:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <31089.1585188206@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IcPRzU31IXfi19056BBo749_gVU>
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:36:35 -0000

On 26-Mar-20 15:03, Michael Richardson wrote:
> 
> 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?

FYI, plenary was fine in NZ, over lunchtime (Thursday). I was there, I just
didn't talk. PST and PDT have reasonable overlaps with us and with AU. It gets
harder as you go further East.

Time zones close to UTC are the worst for NZ, so a plenary on Madrid time
would be a pain for me (and Jay Daley).

> (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)

Kiwis and Aussies would have to get up pretty early for the regular
sessions.

There are excellent tools around, e.g. https://www.timeanddate.com/time/map/
You can even find out the time in Kangerlussuaq or Qaanaaq.

   Brian