IETF Logo Mail Archive

Re: [Taps] Should TAPS meet during IETF-108?

tom petch <daedulus@btconnect.com> Tue, 26 May 2020 16:21 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAC3A0A07; Tue, 26 May 2020 09:21:28 -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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.onmicrosoft.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 GVU1P_2qJUqZ; Tue, 26 May 2020 09:21:17 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70124.outbound.protection.outlook.com [40.107.7.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526AB3A096A; Tue, 26 May 2020 09:21:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTiUjR0Ce9WP3qekxodlfHwv/56VDA/l/j/OK/QzntJujDE+0e80Mvx/vaB9cSF7M5VgxAKWAyavurlTuObNALGUg3eXISJpKVumTp2Eub7/kWwd7hOOLL7p3jYYKnldQ93XnayezmY6WKZG6iUdOjhkRE2ZP5shtOFXQlOKgYWkkbiICwto9WSswDUSM1exn8A5hSRKk55QV9en5xDZ4io4KlnXDHf5qb6Ty3aDCqQE9n8MKpGwIn8Ja4G+TOH4yuFMfjhGnkmD+rxv+9ZzrFkg7m6tVkKqQt+OGDVWVecH2OjGyY6C58m2iHxrERLV35nRByVZDgWvSJUabDTD8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Cs9ttRyi49U+EaCEQTi+OlYilZyZlC7gycu0AKYuyo=; b=glS2F94Za7EEnAyEG+W4SfKC7AseWWeUKlNvxb8csPvh0q1Nf0myUiHbLugl79OM4viWwe4Lr8GxSyTDMNh1UliRUhAbDFPCs6dYmfV2916XkR06AWrQcEI3v10ilwEMrYYmCTcTvfFMDxvsLauMDmw33I+Lvmzr/IkdFSKCaMN/xiarWqUzY4qbAyQQRp+dkrgk2BpAcnQEHhBRjicqqNqIrf+3rm7G9X46S5MJuipY2m1eoRS+v+oC9JpjsTtUQio2gqFfXd9VImojommfXstGdiPEWDjaT4ItRmVb628AkowOWEGWHz0DCNcy5qG/I8DP+4DbKUIBk++YecNnXg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Cs9ttRyi49U+EaCEQTi+OlYilZyZlC7gycu0AKYuyo=; b=RWSWE6Q8YqW2wfCMb4nU04JyozpNNtuWrW68Aiwtep9AlcdPk8JRRlX1fg24LKOBiBCtUOWzdRGCkpfbugE00SBJ0Ql77K8CQ9+yQrf2eVYs4xX0cP6101fH90PAKANP6IMTLZRsqFAegalyK1WjtNG9uOc24oskzpBCnz6F5lc=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:86::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.13; Tue, 26 May 2020 16:21:05 +0000
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3045.015; Tue, 26 May 2020 16:21:05 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
References: <5A720526-CFF7-4F88-9BC3-2132A4412DFE@gmail.com> <CAM4esxQ019r9rGppsDxPwi-2RSKFM1cPBYxocXZKAy-ZAuTb8Q@mail.gmail.com>
Date: Tue, 26 May 2020 17:20:25 +0100
Message-ID: <1UW9af8kBW.1ZEVJoWKHEM@pc8xp>
In-Reply-To: <CAM4esxQ019r9rGppsDxPwi-2RSKFM1cPBYxocXZKAy-ZAuTb8Q@mail.gmail.com>
From: tom petch <daedulus@btconnect.com>
To: Martin Duke <martin.h.duke@gmail.com>, Aaron Falk <aaron.falk@gmail.com>
Cc: "taps-ads@ietf.org" <taps-ads@ietf.org>, taps WG <taps@ietf.org>
User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28)
X-ClientProxiedBy: LO2P265CA0193.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::13) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from pc8xp (81.131.229.108) by LO2P265CA0193.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17 via Frontend Transport; Tue, 26 May 2020 16:21:04 +0000
X-Originating-IP: [81.131.229.108]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8a315df6-b795-46de-2c6a-08d80190c9ca
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006:
X-Microsoft-Antispam-PRVS: <VI1PR0701MB3006CAD1C2FAB80C7F499659C6B00@VI1PR0701MB3006.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-Forefront-PRVS: 041517DFAB
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: vB2swzawJBSdzYRgGe5TcIJa4C1O+6sNrpxR6eKDF5Y0QX7Lmgz7NCZemxDcdKNlDJ89g+eFIwaa9hUU25CEEjuSYNm5g7a4PXEGQ3cOnsTX+H7wIIw0OEF3yS3jYb2KQesw0kkO6PLDQdDNSLD2xxteu9mcUhNqDjlmtpO1nj+C7Uf/xjF4SoVrffYDrBaNzPiLVp9rxHCeJ+fUpju9NmI0EjPVOz7yKGgeq3oJDinpQvfc85ZGJLAdB8RtnAtVYfkpumi6akSgm1TC5y+f75E9ciyglkMpkK4m/veZm1UbjMF3sYfETlNj8aexoA0Mf/3v/hobmhdHFGkU88taznM2KbrKFQk3qYH1EW04Tm4n85UdER0WxqVTzVC6CPMxCerHY0DxofzjYlCDVO8Rdg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(55016002)(498600001)(45080400002)(8676002)(2906002)(4326008)(6496006)(53546011)(8936002)(186003)(16526019)(26005)(66556008)(33716001)(110136005)(52116002)(66476007)(9686003)(54906003)(66946007)(9576002)(86362001)(966005)(956004)(6666004)(52230400001)(5660300002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: CrqgroMyOjiKJAws6sD1lp48ACM5YatOM86v5BDfD8PZetwlGDDaSbP9mmXCXc1x1We6+gy7PnqUxui2b4tqeO22z8psnqTfIUQyAKwUYCq5/2uS7ncrk51aUVqadAU2d74VU0jmEzJmZ8lCTnGhLcfEESocjrxEHbiout6rPdt4NEUYGKLyhjLmzNDA1ngg0ElY4LxfNj9iiDjbnjLCdvI7dulmN6RAqYGtH08Cch6oLmlDjTPKxak5e2OUYsVeV9aQYFvAHET9GNCucEB1Y0CWiGrKGUmJutE9PgCd46cPyy8MZNSAX6g786QZO0yzCLHkpg/ldc//1bZzWWpKfIDGpJf9IstnYBDw99F2unLmpbIkNtbW+/ub3PQq+Gw4SZQumKf3tVq9Yncm6/8fBIEaoShVHEvHJGtolCJiy6pj0SbrAX7PIbz1JcE+C5m9bDDXYgCUVIlEf5wPzqhBDfsZt5VEtb953a1j1dgGzRA=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a315df6-b795-46de-2c6a-08d80190c9ca
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2020 16:21:04.9231 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AdL+D55eKSciUEgytQcaDC7RO8IeCHxVZy6FhPrgJ4dm3oFJDyjLkEXbV0P8p9C3q67lVCcaNa3hdhhIlrwmgw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/bPcqOGycU07FEJfhcq2ZGK5Ou8k>
Subject: Re: [Taps] Should TAPS meet during IETF-108?
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 16:21:35 -0000

----- Original Message -----
From: Martin Duke martin.h.duke@gmail.com
Sent: 26/05/2020 17:09:58

Frankly, I can’t think of a good reason to do so. 

<tp>  IETF meetings have a standing that interim do not, with proceedings, minutes, slide decks and so on.  I wanted to know what happened in a WG in 106 and knew exactly where to go, what to look for and so on.  If the work had been done in an interim then I would have struggled to find what materials, if any, had been produced, which of the multiple interim to look for what; IETF are always good at keeping the WG informed but interim are a lot worse.
Think of compressed video; every so often it sends the complete picture so that if lost or corrupted packets have cost synch then the stream can be got back on track, with delta frames until the next one.
There has been a big growth in virtual interim lately and I think that that will change the working of the IETF and not in a good way; the outcome of the pandemic seems likely to cause permanent changes making travel more expensive in time and money and so it may be several 'IETF' before we meet again in person (or - conceivably - never).
Tom Petch
</tp>

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/



Although I don't have a strong opinion on this question, the reasons to participate in 108 proper are:
- full support for meetecho, archiving, proceedings, etc
- more participation from "tourists" who have already adjusted their schedules for that week
- scheduling that ensures the remote meeting time moves around during the year, meaning it's not always scheduled for the convenience of the usual suspects.


If that's not compelling for the WG, that's fine with me.
Martin


On Tue, May 26, 2020 at 7:17 AM Aaron Falk <aaron.falk@gmail.com> wrote:

Dear TAPS working group & ADs,
Scheduling has begun for the online IETF-108 meeting in July. Should we request a meeting slot for IETF week? Frankly, I can’t think of a good reason to do so. We’ve been making good progress with ~monthly Webex sessions and my hope is to continue them. Trying to schedule a meeting during IETF week will only reduce availability of participants. Thoughts?
--aaron

v2.23.0 | Report a Bug | By Email