Re: [Recentattendees] [104all] Further Clarification Re: IETF 104 Preliminary Agenda

Kyle Rose <> Mon, 25 February 2019 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19D97130FF6 for <>; Mon, 25 Feb 2019 12:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSaopAjkt2Oz for <>; Mon, 25 Feb 2019 12:26:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A4B4130FB8 for <>; Mon, 25 Feb 2019 12:26:13 -0800 (PST)
Received: by with SMTP id o184so4185113ywo.5 for <>; Mon, 25 Feb 2019 12:26:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=onyFgb3xHCe4YbcgWAvW5VrdVyRGQfaqlKFhTmP4Yjc=; b=YgJdAEMWQkrPoSci86xhqHnZ7jXF9pl3sR+41Bf9EIKqooaK65T5wyfygNxQQtW1mb b9OTXnUPyK4x4lar+mhdjY9waxnCvQCM6i6GLS2/kphaW6+EP13pAM8ndbwp4FFPIdrC J6y+ZM6zKcFsEYzWOheWonm8/xE4CW3lYdNJ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=onyFgb3xHCe4YbcgWAvW5VrdVyRGQfaqlKFhTmP4Yjc=; b=DaXXfQyl+4dBLSpdKfbiN6VKvsnKXHSKD5P7VNF+71niSAGxlgLhWtv1m/Kah1pZ9N SYWJrj6YhBIJ5eGa+Qh8oJ3gi7JL3KTBXJt6OtLssowpIMa+dSe05PtsqZJkjygJ5PhL 3RVF2fa83XvRmm+BPd+sAlvPlRCjSiOn0caLFq99WDUE4Bgal4OeTD0+7GcIKODjehpB LpTA+SfVVCtFITNA1r2PgFYn4IxR83Gr7BT9SkYb7GsMxzkSxo9cUrRH0dC6vfTjO4j7 KBRkyUneHRUPLAcGCj7HGYz1DpBYIjEIL3lD9HntmNReu/u5CZU+hTLI212aSQT9jxyx jHZA==
X-Gm-Message-State: AHQUAua/rHNf/Mb00gih/NTSojggqzXhIW2VyqTKJGjN3tx7a4mwVq6e jpDKDQbjIOYBFYr45RLiCL7Zp9xjauveHlXi9JdJHA==
X-Google-Smtp-Source: AHgI3IbyzZkHdju05I8CpL51170tpy9cpUD5AJTwX5iLxPbMEs8CTm7/BswCnp1koE7zvKtRjZLC0GZn3V/a5VQEtqk=
X-Received: by 2002:a0d:d8c3:: with SMTP id a186mr15459181ywe.221.1551126372392; Mon, 25 Feb 2019 12:26:12 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Mon, 25 Feb 2019 15:26:00 -0500
Message-ID: <>
Cc: IETF Announcement List <>, WG Chairs <>,, IETF Discussion Mailing List <>,
Content-Type: multipart/alternative; boundary="0000000000006db3880582bdc055"
Archived-At: <>
Subject: Re: [Recentattendees] [104all] Further Clarification Re: IETF 104 Preliminary Agenda
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Recent IETF Attendees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Feb 2019 20:26:17 -0000

There seem to be two separate issues here:

1. The meeting ends on Friday.

2. There is some combination of too few slots, too many (or too long) WG
session requests, and not enough information about meaningful conflicts to
construct a viable schedule.

#2 is a problem that the secretariat can partially address through changes
to the conflict declaration process. For example, by allowing chairs to
specify *individuals* who need to be at particular sessions because they're
presenting or are heavily involved in work, rather than via the working
group proxy, which may (and does IME) encode preference as well as need,
may become stale over the course of meetings, and often fails to capture
critical conflicts. This is a hard problem, but if it's possible to get a
viable schedule for the requested WG sessions given the number of slots,
there is a solution.

The secretariat can't address the problem of too many (or too long) WG
sessions, because it's a judgment call on the part of those involved in the
WGs. Perhaps sponsoring ADs can get more involved in deciding whether a WG
really needs to consume an official meeting slot, or whether they really
need as much time as requested for in-person work. This is also a hard
problem, but if we're going to make the most efficient use of limited
official in-person meeting time, hard choices will need to be made. (IMO,
leave the draft status updates to the mailing list. Use the meeting for
issues chosen in advance that will benefit from in-person discussion and

#1, by contrast, is an easy problem to solve. Your WG can be assigned to a
slot anywhere from Monday to Friday at the secretariat's discretion.
Therefore: don't schedule your return trip until late on Friday at the
earliest, or don't complain when you are scheduled to leave before the
meeting ends. Which is on Friday. Seems straightforward.


On Sat, Feb 23, 2019 at 12:08 AM IETF Agenda <> wrote:

> Hi everyone,
> Our message earlier today announcing the preliminary agenda [1] was
> missing some further context. As previously mentioned by Alissa after IETF
> 103 [2], the IESG wanted to continue the unstructured time experiment at
> IETF 104.
> Wednesday's schedule has regular sessions until 13:20, unstructured time
> in the afternoon, and the plenary in the evening at 17:10. This leaves
> almost four hours of unstructured time for attendees to reserve for side
> meetings. During this period, there will also be one unique Technology Deep
> Dive session with the acronym WGTLGO [3].
> Monday through Friday, we will have two rooms available for attendees to
> reserve for side meetings as usual. On Wednesday afternoon, we will have
> five rooms available for side meetings. Further details about how to sign
> up for these rooms will be announced shortly.
> Thanks,
> IETF Secretariat
> [1]
> [2]
> [3]
> --
> 104all mailing list