Re: [irsg] IETF 114 - Working Group/BOF/IRTF Scheduling

Robert Sparks <rjsparks@nostrum.com> Thu, 28 April 2022 13:56 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC5C15E6CE for <wgchairs@ietfa.amsl.com>; Thu, 28 Apr 2022 06:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level:
X-Spam-Status: No, score=-3.932 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_8GfYGUwxis for <wgchairs@ietfa.amsl.com>; Thu, 28 Apr 2022 06:56:55 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35607C15E6C7 for <wgchairs@ietf.org>; Thu, 28 Apr 2022 06:56:55 -0700 (PDT)
Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 23SDuliu031744 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <wgchairs@ietf.org>; Thu, 28 Apr 2022 08:56:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1651154213; bh=4wNVq+wVcaSTE9RMZyQdq0sRdD8+Moht7WKnMaFZ+wc=; h=Date:To:References:From:Subject:In-Reply-To; b=O0mHX17zoEi8EYCM805FfzI8KYxLHUgYnjyNfWVKq9XviRXVuRQMdl+I7UyFKxx38 9ltGAQPNFj0EzN1/4jncTyJo8VkfJamQzfedelKWxjX8q0DY8QkICaejdgaEbirAK3 HHH9dCK+TAlPBzaEXRizP5wiPaOzl6L3kcZdPxz4=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114]
Content-Type: multipart/alternative; boundary="------------3V64GpyqeiQ2Ex5FF9EVPuk5"
Message-ID: <aa5d1cfa-fbaf-ddb9-a164-d875fae34450@nostrum.com>
Date: Thu, 28 Apr 2022 08:56:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Content-Language: en-US
To: wgchairs@ietf.org
References: <165099131006.2413.18420729450963190676@ietfa.amsl.com> <db6e3b6e-d4a8-3e67-6871-1fb8371f5c35@nostrum.com> <e8561c16-a730-38b2-7dd1-427270ecfb9a@nostrum.com> <47d3b244-d50f-0290-925b-24967026dad5@nostrum.com> <CALaySJLcTDwkRqr5s3qh8mdN-AB4=mosgt1q1WjvYEODSvavCA@mail.gmail.com> <m235hxhd6n.fsf@ja.int.chopps.org> <AA7F1F0E-3DEA-4DFB-9CE0-F3E0EA04FAA0@tzi.org>
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [irsg] IETF 114 - Working Group/BOF/IRTF Scheduling
In-Reply-To: <AA7F1F0E-3DEA-4DFB-9CE0-F3E0EA04FAA0@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/YJUL7D2U9XGJ1rJzUuNiZOovPjI>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 13:56:59 -0000

Yes, an upcoming release will make this all more obvious - the field 
will clearly signal "Anyone but the AD who must be there" and the 
request result will clearly show that the AD is required.

The scheduling tool _separately_ already knows that a group's AD should 
be there, and shows a different badge when there's a conflict for that AD:

When the AD is listed explicitly in "be there", and there aren't any 
other be-there conflicts, a second "be-there" conflict badge shows up, 
and eventually, the secretariat and the IESG start ignoring the be-there 
badge as noise,  and not react as well when there's an actual chair 
conflict.

Here's an example from 113 where Roman needed to be two places at once, 
and he was the only be-there conflict (the person badge with the 1 next 
to it)

Now, yes, the code displaying the schedule can clean that case away, and 
in some circumstances we will do so, but we're going to focus on 
improving the data going in, and all my note was for was to ask for 
early help on that.

It makes sense to include chairs in the be-there field as we have 
multiple chairs for groups and sometime chairs decide its ok for chair-a 
to go do something else while chair-b attends the session (chair-a might 
be must-be-there as a document editor in some other group).

That ADs can ask other ADs to cover groups when they're in conflict is 
handled _in person_ during the conflict resolution process where all the 
ADs are present.

RjS


On 4/28/22 3:33 AM, Carsten Bormann wrote:
> And since the damage from not recording an AD “be there” can be significant, I’m not happy that we are asked to rely on a mechanism that we can’t see whether it’s doing its work.
>
> Grüße, Carsten
>
>
>> On 2022-04-28, at 09:33, Christian Hopps<chopps@chopps.org>  wrote:
>>
>>
>> I wondered the same thing. I removed the chairs and the AD. The visual feedback I got was that it now says:
>>
>>    People who must be present:          None
>>
>> which to be honest seems a lot more confusing that if it showed the AD and chairs. Not sure what visual noise we're avoiding here.
>>
>> Thanks,
>> Chris.
>>
>> Barry Leiba<barryleiba@computer.org>  writes:
>>
>>> The chairs, too, I presume, yes?
>>>
>>> Barry
>>>
>>> On Wed, Apr 27, 2022 at 10:10 AM Robert Sparks<rjsparks@nostrum.com>  wrote:
>>>> The session request tool issue has been resolved. Please resume
>>>> requesting sessions.
>>>>
>>>> NOTE: An upcoming release will make it clear that you should not include
>>>> your AD in the "must be present" list. The scheduling tool already knows
>>>> that a Working Group's AD needs to be present, and including them in the
>>>> must-be-present list introduces unnecessary visual noise. Please remove
>>>> the AD from the list as you're making your session requests this time.
>>>>
>>>> RjS
>>>>
>>>> On 4/26/22 4:58 PM, Robert Sparks wrote:
>>>>> Update: We expect to put a release into production tomorrow that will
>>>>> address this issue.
>>>>>
>>>>> RjS
>>>>>
>>>>> On 4/26/22 1:06 PM, Robert Sparks wrote:
>>>>>> There is an issue with session requests at the moment (all are
>>>>>> failing). Seehttps://github.com/ietf-tools/datatracker/issues/3889
>>>>>> for status. I'll send another note here when the issue is resolved.
>>>>>>
>>>>>> RjS
>>>>>>
>>>>>> On 4/26/22 11:41 AM, IETF Agenda wrote:
>>>>>>> -----------------------------------------------------------------
>>>>>>> IETF 114 – Philadelphia, PA, USA
>>>>>>> Meeting Dates: July 23-29, 2022
>>>>>>> -----------------------------------------------------------------
>>>>>>>
>>>>>>> We are now accepting scheduling requests for all Working Groups and
>>>>>>> Research Groups until Friday, June 10, 2022 and BOF requests until
>>>>>>> Friday, May 27, 2022.
>>>>>>>
>>>>>>>
>>>>>>> ===========================================================
>>>>>>> What’s New for IETF 114
>>>>>>>
>>>>>>> The session request form will ask you to estimate the number of
>>>>>>> people attending. Please make your best guess as to the total number
>>>>>>> of participants, based on your last several online sessions and
>>>>>>> in-person at IETF 113 if applicable. When we assign conference rooms
>>>>>>> at the meeting, we will make room size estimates based on the
>>>>>>> proportion of in-person registrations.
>>>>>>>
>>>>>>> Requests for more than two hours of total meeting time are unlikely
>>>>>>> to succeed. In special cases, you may request more than two hours of
>>>>>>> meeting time, but the IESG will likely request a rationale, and
>>>>>>> scheduling pressure may still make it impossible to grant any
>>>>>>> additional meeting slots. Please see this email from the IESG [1]
>>>>>>> for more detailed guidance on how to structure your session requests.
>>>>>>>
>>>>>>> As of IETF 112, BOFs are now requested via the Datatracker instead
>>>>>>> of the wiki. Please see the BoF section of this email below for more
>>>>>>> details.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://mailarchive.ietf.org/arch/msg/wgchairs/_x2nc9Xqa5i1U4SuEFs3eggTCyk/
>>>>>>>
>>>>>>> ===========================================================
>>>>>>> How to Request a WG or RG Session
>>>>>>>
>>>>>>> Requests to schedule Working Group or Research Group sessions should
>>>>>>> be submitted using the "IETF Meeting Session Request Tool." The URL
>>>>>>> for the tool is:
>>>>>>>
>>>>>>> https://datatracker.ietf.org/secr/sreq/
>>>>>>>
>>>>>>> If you require an account on this tool, or assistance in using it,
>>>>>>> then please send a message tosupport@ietf.org.  If you are unable
>>>>>>> to use the tool, then you may send your request via email to
>>>>>>> support@ietf.org, with a copy to the appropriate Area Director(s).
>>>>>>>
>>>>>>> As a reminder, the conflict list options are:
>>>>>>>
>>>>>>> - Chair Conflict: to indicate other WGs the Chairs also lead, or
>>>>>>> will be active participants in the upcoming meeting
>>>>>>>
>>>>>>> - Technology Overlap: to indicate WGs with a related technology or a
>>>>>>> closely related charter
>>>>>>>
>>>>>>> - Key Participant Conflict (e.g., presenter, Secretary, etc.): to
>>>>>>> indicate WGs with which key participation may overlap in the
>>>>>>> upcoming meeting
>>>>>>>
>>>>>>> The Special Request field will continue to be available for more
>>>>>>> specific needs, and Responsible AD conflicts are already taken into
>>>>>>> consideration. Please make sure you take a few minutes to check your
>>>>>>> conflict lists carefully!
>>>>>>>
>>>>>>> ===========================================================
>>>>>>> How to Request a BOF
>>>>>>>
>>>>>>>
>>>>>>> The BOF deadline is on May 27. The intent of this earlier deadline
>>>>>>> is to allow BOF proponents time to work more closely with the IESG
>>>>>>> and IAB to develop their proposal before final approval
>>>>>>> determinations. If your initial proposal needs further work you may
>>>>>>> revise and resubmit before final decisions must be made.
>>>>>>>
>>>>>>> BOFs will NOT be scheduled unless the Area Director approves the
>>>>>>> BOF. The proponents behind a BOF need to contact a relevant Area
>>>>>>> Director, preferably well in advance of the BOF approval deadline
>>>>>>> date. The AD needs to have the full name of the BOF, its acronym,
>>>>>>> suggested names of chairs, an agenda, full description of the BOF
>>>>>>> and the information below. Please refer to
>>>>>>> https://datatracker.ietf.org/doc/bof-requests/new/  for more
>>>>>>> information about planning a BOF. You will need a Datatracker
>>>>>>> account to submit a BOF request.
>>>>>>>
>>>>>>> You MUST provide the following information before a BOF session will
>>>>>>> be scheduled:
>>>>>>>
>>>>>>> a. BOF full name with acronym in brackets
>>>>>>> b. AREA under which the BOF appears
>>>>>>> c. CONFLICTS you wish to avoid, please be as specific as possible
>>>>>>> d. Special requests
>>>>>>> e. Number of sessions
>>>>>>> f. Length of session: 60 minutes or 120 minutes
>>>>>>>
>>>>>>>
>>>>>>> ===========================================================
>>>>>>> Deadlines
>>>>>>> Cut-off dates are subject to change.
>>>>>>>
>>>>>>> • 2022-04-26 (Tuesday): Working Group and BOF scheduling begins.
>>>>>>> • 2022-05-27 (Friday): Cut-off date for BOF proposal requests.
>>>>>>> • 2022-06-10 (Friday): Cut-off date for requests to schedule Working
>>>>>>> Group meetings at UTC 23:59.
>>>>>>> • 2022-06-17 (Friday): Cut-off date for Area Directors to approve
>>>>>>> BOFs at UTC 23:59.
>>>>>>> • 2022-06-24 (Friday): Preliminary agenda published for comment.
>>>>>>> • 2022-06-29 (Wednesday): Cut-off date for requests to reschedule
>>>>>>> Working Group and BOF meetings UTC 23:59.
>>>>>>> • 2022-07-01 (Friday): Final agenda to be published.
>>>>>>> • 2022-07-13 (Wednesday): Draft Working Group agendas due by UTC 23:59.
>>>>>>> • 2022-07-18 (Monday): Revised Working Group agendas due by UTC 23:59.
>>>>>>>
>>>>>>>
>>>>>>> ===========================================================
>>>>>>>
>>>>>>> Submitting Session Agendas
>>>>>>>
>>>>>>> Please submit the agendas for your sessions as early as possible
>>>>>>> using the "IETF Meeting Materials Management Tool," a Web-based tool
>>>>>>> for making your meeting agenda, minutes, and presentation slides
>>>>>>> available to the community before, during, and after an IETF
>>>>>>> meeting.  If you are a BOF chair, then you may use the tool to
>>>>>>> submit a revised agenda as well as other materials for your BOF once
>>>>>>> the BOF has been approved.
>>>>>>>
>>>>>>> The URL for the tool is:
>>>>>>>
>>>>>>> https://datatracker.ietf.org/secr/proceedings/
>>>>>>>
>>>>>>> Agendas submitted via the tool will be available to the public on
>>>>>>> the "IETF Meeting Materials" webpage as soon as they are submitted.
>>>>>>>
>>>>>>> The URL for the "IETF 114 Meeting Materials" Web page is:
>>>>>>>
>>>>>>> https://datatracker.ietf.org/meeting/114/materials.html
>>>>>>>
>>>>>>> If you are a Working Group chair, then you already have accounts on
>>>>>>> the "IETF Meeting Session Request Tool" and the "IETF Meeting
>>>>>>> Materials Management Tool."  The same User ID and password will work
>>>>>>> for both tools.  If you are a BOF chair who is not also a Working
>>>>>>> Group chair, then you will be given an account on the "IETF Meeting
>>>>>>> Materials Management Tool" when your BOF has been approved.  If you
>>>>>>> require assistance in using either tool, or wish to report a bug,
>>>>>>> then please send a message tosupport@ietf.org.
>>>>>>>
>>>>>>> ===============================================================
>>>>>>> Area Director Contact Information
>>>>>>>
>>>>>>> IETF Chair
>>>>>>> Lars Eggert<lars@eggert.org>
>>>>>>>
>>>>>>>    Applications and Real-Time Area (art)
>>>>>>> Murray Kucherawy<superuser@gmail.com>
>>>>>>> Francesca Palombini<francesca.palombini@ericsson.com>
>>>>>>>
>>>>>>>    Internet Area (int)
>>>>>>> Erik Kline<ek.ietf@gmail.com>
>>>>>>> Éric Vyncke<evyncke@cisco.com>
>>>>>>>
>>>>>>>
>>>>>>> Operations & Management Area (ops)
>>>>>>> Warren Kumari<warren@kumari.net>
>>>>>>> Robert Wilton<rwilton@cisco.com>
>>>>>>>
>>>>>>>
>>>>>>> Routing Area (rtg)
>>>>>>> Andrew Alston<andrew-ietf@liquid.tech>
>>>>>>> John Scudder<jgs@juniper.net>
>>>>>>> Alvaro Retana<aretana.ietf@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>> Security Area (sec)
>>>>>>> Roman Danyliw<rdd@cert.org>
>>>>>>> Paul Wouters<paul.wouters@aiven.io>
>>>>>>>
>>>>>>>    Transport Area (tsv)
>>>>>>> Martin Duke<martin.h.duke@gmail.com>
>>>>>>> Zaheduzzaman Sarker<Zaheduzzaman.Sarker@ericsson.com>
>>>>>>>