From nobody Tue Oct 1 08:31:07 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F5120886 for ; Tue, 1 Oct 2019 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 gJibqCK9Hd2Z for ; Tue, 1 Oct 2019 08:31:03 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 AED6E120860 for ; Tue, 1 Oct 2019 08:30:59 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id r5so22166911qtd.0 for ; Tue, 01 Oct 2019 08:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nL1dEsOTOuoD4dH50yA6u5AxjyHJtGM8wZ1aDBC5Wtc=; b=KOCca439NTvZKEZqtmDUJolz5TNkgySKLRekcaYS0lo4uO7+uk4JjvLXFwLsF6e1uN PIA6lmWRpLI47lV0YSGGUILZBvmL6GdTJK8ePM7KHuP7z9qSVu1Za8GUOznY6B1UXahM /FF/MRbsZsR7YF2K0i0Vd+CtIiT3Ls6+GXO1U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nL1dEsOTOuoD4dH50yA6u5AxjyHJtGM8wZ1aDBC5Wtc=; b=WfXqUH/O4xWEzEkZmLMvcqY8QqcWtC7LIv4C4fB5mIWe+p66vssHdcHllW1eOr1+TV PnPlru48srYM4kvzenroIFeAlEqOgQY/rDdAyNWZwgR+eobjaQF94MeYWBpX+se4qMOH 31kHjnUo9vdkP43HOjML6v4LUk3IM9ylJrqDR2Zi1NOGwyTACDiYHpnMffZeKljD9uD/ 93a+CvPSnKlrw9f5VwYTHOyi3BEwiAPtD/Bf32VF33sKM7zRNnB7k0MvFl4zaoSue8p4 dnvm3WloPkSJGO+GMM80jCVnjSJtdu+CvDaZWDjrOEvehwGa9SLjhgNGEJd8Mf+08GLi DY1A== X-Gm-Message-State: APjAAAW5pPg53wH5iryKe8411cYlxWahggEAFWuu0z9t773ysUqjGGAf BhRvJ08cUFoXNNY3Q+FZSzhUZw== X-Google-Smtp-Source: APXvYqyE6tzXDR2jqxtQRGRKejPJXt0bDUX3XNzhCwylcZYSLJNL9vcNT6jaWayRASYAvpTbeyl8JQ== X-Received: by 2002:ac8:65c5:: with SMTP id t5mr23095446qto.217.1569943858729; Tue, 01 Oct 2019 08:30:58 -0700 (PDT) Received: from ?IPv6:2a06:98c0:1000:8800:2c45:f2bd:808b:f893? ([2a06:98c0:1000:8800:2c45:f2bd:808b:f893]) by smtp.gmail.com with ESMTPSA id x15sm7505291qkh.44.2019.10.01.08.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 08:30:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> Date: Tue, 1 Oct 2019 16:30:55 +0100 Cc: gendispatch@ietf.org, IETF-Announce Content-Transfer-Encoding: quoted-printable Message-Id: <1ED85E0F-0CB2-450F-8D55-AA6D2027D72E@sn3rd.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 15:31:06 -0000 I am in favor of this proposal. One question below: > On Sep 26, 2019, at 23:44, The IESG wrote: >=20 > f the group decides that a particular topic needs to be addressed by a = new > WG, the normal IETF chartering process will be followed, including, = for > instance, IETF-wide review of the proposed charter. Proposals for = large work > efforts SHOULD lead to a BOF where the topic can be discussed in front = of the > entire IETF community. Documents progressed as AD-sponsored would = typically > include those that are extremely simple or make minor updates to = existing > process documents. Is the AD in this case always the IETF Chair? I am somewhat concerned = about increasing the workload of the IETF Chair when the I-D might doing = something so minor (and possibly noncontroversial) that any AD could = sponsor the I-D. spt= From nobody Tue Oct 1 10:47:39 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D937120058 for ; Tue, 1 Oct 2019 10:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 rKKSp2KPQisF for ; Tue, 1 Oct 2019 10:47:30 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 494751200BA for ; Tue, 1 Oct 2019 10:47:30 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id c3so22669988qtv.10 for ; Tue, 01 Oct 2019 10:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1+aIiIEmsJn5GUtdvQ/HDB7bMIIUMUPEB612qcm6Y1c=; b=HIP4PzX7n1FJPZh0R+vwnpJFrqab8FvZaEhO9JTQpeglXkWWnlrTnXdTPhd05sD+v/ 2+9BFDhs2axf8zehUmBlYzC6O7Yy1uHibQ8B3cqkWpxift8YBw2E0GPuvG2q3Ht594Yq Z+czAYxZPfDi38Ez0ihE9OJFU6jOdQ1mIemL8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1+aIiIEmsJn5GUtdvQ/HDB7bMIIUMUPEB612qcm6Y1c=; b=F5tWFwZ8Jx4kXPGIg6r2DXdIUvJS6QATWemIr73P2mkwPVUU4PNFaie163jS9eDt0r Wgpu0wzpTKuAZ80GmzTxxh+In1rlVfg1ViN/mwSCkM9epxTis481NGy2nMu5ji0Spv/S 9W7Q+2vvC6vGBUISEbBVtSfUvMf9N996mJm0wmZqo97WOIOr4/p1Lm95YeOvPab1uH97 BubjZGHEp/L9kVmH2RdQJez6djrBD69Qk6fxKFG4ot/1bTjTQio8+829r2ZZ9uf3kKQg loAriwTZLo8GSQhDbj1oy9/ZC2PaQFiCVzTptetkkZaEq3eWIsTtS6DPw9n5cuREmgTt mHpQ== X-Gm-Message-State: APjAAAWhO9kcBYNHEp4hCe7rnDyU1dETuwzcH78skv0tLSfI0rAzQYDe UY1sJAtZ2RJRR7if5TuOxgBzhw== X-Google-Smtp-Source: APXvYqxsmXHY61dTp+pkbN7RtGw2/pg7EdAmdKmqWtoTz0rwYz2lBzv16gahfVUe2bu96XoHFo+89g== X-Received: by 2002:ac8:27d9:: with SMTP id x25mr8317511qtx.321.1569952049345; Tue, 01 Oct 2019 10:47:29 -0700 (PDT) Received: from [5.5.33.147] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id 187sm7693014qki.80.2019.10.01.10.47.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 10:47:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <1ED85E0F-0CB2-450F-8D55-AA6D2027D72E@sn3rd.com> Date: Tue, 1 Oct 2019 18:47:26 +0100 Cc: gendispatch@ietf.org, IETF discussion list Content-Transfer-Encoding: quoted-printable Message-Id: <0D7F3F61-9789-41B5-B41D-65BD31353EB2@sn3rd.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <1ED85E0F-0CB2-450F-8D55-AA6D2027D72E@sn3rd.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 17:47:32 -0000 apologies for the double send. > On Oct 1, 2019, at 16:30, Sean Turner wrote: >=20 > I am in favor of this proposal. One question below: >=20 >> On Sep 26, 2019, at 23:44, The IESG wrote: >>=20 >> f the group decides that a particular topic needs to be addressed by = a new >> WG, the normal IETF chartering process will be followed, including, = for >> instance, IETF-wide review of the proposed charter. Proposals for = large work >> efforts SHOULD lead to a BOF where the topic can be discussed in = front of the >> entire IETF community. Documents progressed as AD-sponsored would = typically >> include those that are extremely simple or make minor updates to = existing >> process documents. >=20 > Is the AD in this case always the IETF Chair? I am somewhat concerned = about increasing the workload of the IETF Chair when the I-D might doing = something so minor (and possibly noncontroversial) that any AD could = sponsor the I-D. >=20 >=20 > spt From nobody Fri Oct 4 10:14:37 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D5A120143; Fri, 4 Oct 2019 10:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=TageJwm5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eanTCZny 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 FMrm8JnVCvtB; Fri, 4 Oct 2019 10:14:27 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ED71208EB; Fri, 4 Oct 2019 10:14:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5543422033; Fri, 4 Oct 2019 13:14:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 04 Oct 2019 13:14:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=9UFy+5BXXTGPzJoa6IX9gLD TAIYZcfjEWnjGDbLJzZQ=; b=TageJwm5IxqIuhctkQejxpLfiK9JeX+8uF1n7ru oVCKUp1sl1RayiILdx+Y/PpW2aX7gdqVK7OqY2YINJXIAXr5uClm1t9v6lrJmK3e R9ya1thKQocbOH0vq5ZN6PnMni48N6PLTRuJuCfGKIlCng/3Bue5WCQrRVJZs4/7 pUZcH1Cfz+9zXT/19raIYcg0gqnhqpGW7B5vKyWn8dpd/4oI1y+1PeJ/W5g/B77y LIneG8/l6IEE3L19PcS2qWKM3xGBuJsOQ42LxXv9ILtR6tFXwFUrFqHzppzKJAwm D9b1xF2835UDQkF9p57tW+/ZW7NZaI3pw8L161F4L1ftoiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9UFy+5 BXXTGPzJoa6IX9gLDTAIYZcfjEWnjGDbLJzZQ=; b=eanTCZnyH8t4VA6nAJpguM WJkoBWNp5/8RCy0CUP417h9gBWZgr+Zz9F8VagH9pw6bEZdeSLjqB5KopD4vKaak Co4bvQm6Dm5+fIqIJOeCIaw596/xtEtc60WnP+NQw/1lYbOjFlGm4KGp0e6ZU9MW Ps/5KwwfEBADUUPoTvViYWdafo/0gmwgV+3lw3SpNN/vpOEtkDHqRffq3/0Pa0nD zC63rwTvViCFe3OTJ8NKpuH5Xz7DdEMshEipQQiXXj4MCI7XcOynQ6B98kIVJRR8 3aJWeoDwvt4s5EGLPOczdtzi4eDJebldZD6ec2+4xc/8TM9HSl19ydPhSdWaysZw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrhedugddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhkfgtggfuffgjvfhfofesrgdtmh erhhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrgestgho ohhpvghrfidrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrd ehuddruddtuddrleeknecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestgho ohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 92F2580062; Fri, 4 Oct 2019 13:14:25 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_350CF455-D409-4383-A9D7-1AC8FD43FB31" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 4 Oct 2019 13:14:24 -0400 In-Reply-To: Cc: IETF , gendispatch@ietf.org To: Eric Rescorla References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 17:14:31 -0000 --Apple-Mail=_350CF455-D409-4383-A9D7-1AC8FD43FB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ekr, > On Sep 28, 2019, at 4:24 PM, Eric Rescorla wrote: >=20 > First, let me say that I am broadly in favor of this proposal. > IMO, DISPATCH-style WGs have been very successful in both > SEC and ART. I have a couple of small comments. >=20 >=20 > Group page: https://datatracker.ietf.org/group/gendispatch/ = > > > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ = > > > > The GENDISPATCH working group is a DISPATCH-style working group (see = RFC > > 7957) chartered to consider proposals for new work in the GEN area, = including > > proposals for changes or improvements to the IETF process and = process > > documents. The working group is chartered to identify, or help = create, an > > appropriate venue for the work. The working group will not consider = any > > technical standardization work. >=20 > I think you could read this two ways: >=20 > 1. This WG won't do any standards > 2. This WG won't do any technical work >=20 > So as a concrete example, suppose I had a standards track proposal to > require that WG chairs all wear powdered wigs, that would not be > technical, but I take from the list of options below that it would not > be able to actually advance the work itself, but only recommend > a next step. Is that correct? Yes. >=20 > In that case, perhaps: > "The Working Group will not directly progress any standards > work itself=E2=80=9D. I=E2=80=99m not sure what problem that change would solve. There is = another meaning that the current text conveys that would be lost if that = change were made. If someone tries to bring a specification for a new = audio codec to GENDISPATCH, it will not even be considered. This is = different from the proposal to require chairs to wear wigs, which could = be considered and then dispatched. >=20 > If you mean the latter, maybe just remove the word = =E2=80=9Cstandardization=E2=80=9D The problem with that is that there have occasionally been IETF = tools-related things that have been documented in I-Ds and RFCs (e.g., = https://datatracker.ietf.org/doc/rfc6778/). Although to my eye an RFC is = not a great mechanism for publishing these kinds of things, if the = community wanted to do that then considering such documents in = GENDISPATCH seems warranted. And these could arguably be considered = =E2=80=9Ctechnical work.=E2=80=9D Thanks, Alissa >=20 >=20 > > Proposed new work may be deferred in cases where the WG does not = have enough > > information for the chairs to determine consensus. New work may be = rejected > > in cases where there is not sufficient WG interest or the proposal = has been > > considered and rejected in the past, unless a substantially revised = proposal > > is put forth, including compelling new reasons for accepting the = work. >=20 > We have found this to be a key clause for other DISPATCH-style WGs > so glad to see it here. >=20 > -Ekr >=20 > On Thu, Sep 26, 2019 at 3:48 PM Alissa Cooper > wrote: > Hi all, >=20 > The review period for this charter is a little longer than usual since = this is a proposal for a process-oriented WG that did not go through the = BOF process. As the charter text indicates, the idea of this WG is to = help streamline the consideration of process proposals and leverage the = WG chairs to help guide process discussions. Feedback is welcome. >=20 > Thanks, > Alissa Cooper > General Area AD >=20 >=20 > > On Sep 26, 2019, at 11:44 PM, The IESG > wrote: > >=20 > > A new IETF WG has been proposed in the General Area. The IESG has = not made > > any determination yet. The following draft charter was submitted, = and is > > provided for informational purposes only. Please send your comments = to the > > IESG mailing list (iesg@ietf.org ) by = 2019-10-11. > >=20 > > General Area Dispatch (gendispatch) > > = ----------------------------------------------------------------------- > > Current status: Proposed WG > >=20 > > Chairs: > > Francesca Palombini > > > Pete Resnick > > >=20 > > Assigned Area Director: > > Alissa Cooper > > >=20 > > General Area Directors: > > Alissa Cooper > > >=20 > > Mailing list: > > Address: gendispatch@ietf.org > > To subscribe: > > Archive: > >=20 > > Group page: https://datatracker.ietf.org/group/gendispatch/ = > >=20 > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ = > >=20 > > The GENDISPATCH working group is a DISPATCH-style working group (see = RFC > > 7957) chartered to consider proposals for new work in the GEN area, = including > > proposals for changes or improvements to the IETF process and = process > > documents. The working group is chartered to identify, or help = create, an > > appropriate venue for the work. The working group will not consider = any > > technical standardization work. > >=20 > > Guiding principles for the proposed new work include: > >=20 > > 1. Providing a clear problem statement, historical context, = motivation, and > > deliverables for the proposed new work. > >=20 > > 2. Ensuring there has been adequate mailing list discussion = reflecting > > sufficient interest, individuals have expressed a willingness to = contribute > > (if appropriate given the subject matter of the proposal) and there = is WG > > consensus before new work is dispatched. > >=20 > > 3. Looking for and identifying commonalities and overlap amongst = published or > > ongoing work in the GEN area, within the IESG, or within the IETF = LLC. > >=20 > > Options for handling new work include: > >=20 > > - Directing the work to an existing WG. > >=20 > > - Developing a proposal for a BOF. > >=20 > > - Developing a charter for a new WG. > >=20 > > - Making recommendations that documents be AD-sponsored (which ADs = may or may > > not choose to follow). > >=20 > > - Requesting that the the IESG or the IETF LLC consider taking up = the work. > >=20 > > - Deferring the decision for the new work. > >=20 > > - Rejecting the new work. > >=20 > > If the group decides that a particular topic needs to be addressed = by a new > > WG, the normal IETF chartering process will be followed, including, = for > > instance, IETF-wide review of the proposed charter. Proposals for = large work > > efforts SHOULD lead to a BOF where the topic can be discussed in = front of the > > entire IETF community. Documents progressed as AD-sponsored would = typically > > include those that are extremely simple or make minor updates to = existing > > process documents. > >=20 > > Proposed new work may be deferred in cases where the WG does not = have enough > > information for the chairs to determine consensus. New work may be = rejected > > in cases where there is not sufficient WG interest or the proposal = has been > > considered and rejected in the past, unless a substantially revised = proposal > > is put forth, including compelling new reasons for accepting the = work. > >=20 > > A major objective of the GENDISPATCH WG is to provide timely, clear > > dispositions of new efforts. Thus, where there is consensus to take = on new > > work, the WG will strive to quickly find a home for it. While most = new work > > in the GEN area is expected to be considered in the GENDISPATCH = working > > group, there may be times where that is not appropriate. At the = discretion of > > the GEN AD, new efforts may follow other paths. For example, work = may go > > directly to a BOF, may be initiated in other working groups when it = clearly > > belongs in that group, or may be directly AD-sponsored. > >=20 > > Another major objective of the GENDISPATCH WG is to streamline how = the IETF > > community considers process improvements. Community discussions = about process > > suggestions that begin on other mailing lists, including = ietf@ietf.org , will > > be redirected to the GENDISPATCH mailing list where they will be = facilitated > > by the WG chairs. Proponents of process improvements will be = encouraged to > > craft concrete proposals for discussion on the GENDISPATCH mailing = list, with > > the goal of producing a concrete outcome in bounded time. Direct = requests to > > the IESG may also, after proper consideration, be redirected to the = WG. For > > proposals to be considered by the WG they will be expected to meet = guiding > > principle #1 above. > >=20 > > The existence of this working group does not change the IESG's > > responsibilities as described in RFC 3710. Work related to the IAB, = IRTF, and > > RFC Editor processes is out of scope. > >=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce = >=20 --Apple-Mail=_350CF455-D409-4383-A9D7-1AC8FD43FB31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ekr,

On Sep 28, 2019, at 4:24 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:

First, let me say that I am broadly in favor of = this proposal.
IMO, DISPATCH-style WGs have been very = successful in both
SEC and ART. I have a couple of small = comments.


Group page: https://datatracker.ietf.org/group/gendispatch/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/<= br class=3D"">>
> The GENDISPATCH working group is a = DISPATCH-style working group (see RFC
> 7957) chartered = to consider proposals for new work in the GEN area, including
> proposals for changes or improvements to the IETF = process and process
> documents. The working group is = chartered to identify, or help create, an
> appropriate = venue for the work. The working group will not consider any
> technical standardization work.

I think you could read this two ways:

1. This WG won't do any standards
2. This WG = won't do any technical work

So as a = concrete example, suppose I had a standards track proposal to
require that WG chairs all wear powdered wigs, that would not = be
technical, but I take from the list of options below = that it would not
be able to actually advance the work = itself, but only recommend
a next step. Is that = correct?

Yes.


In = that case, perhaps:
"The Working Group will not directly = progress any standards
work itself=E2=80=9D.

I=E2=80= =99m not sure what problem that change would solve. There is another = meaning that the current text conveys that would be lost if that change = were made. If someone tries to bring a specification for a new audio = codec to GENDISPATCH, it will not even be considered. This is different = from the proposal to require chairs to wear wigs, which could be = considered and then dispatched.


If you mean the latter, maybe just remove the word = =E2=80=9Cstandardization=E2=80=9D

The problem with that is that there have = occasionally been IETF tools-related things that have been documented in = I-Ds and RFCs (e.g., https://datatracker.ietf.org/doc/rfc6778/). Although to = my eye an RFC is not a great mechanism for publishing these kinds of = things, if the community wanted to do that then considering such = documents in GENDISPATCH seems warranted. And these could arguably be = considered =E2=80=9Ctechnical work.=E2=80=9D

Thanks,
Alissa



> Proposed new = work may be deferred in cases where the WG does not have enough
> information for the chairs to determine consensus. New = work may be rejected
> in cases where there is not = sufficient WG interest or the proposal has been
> = considered and rejected in the past, unless a substantially revised = proposal
> is put forth, including compelling new = reasons for accepting the work.

We have = found this to be a key clause for other DISPATCH-style WGs
so glad to see it here.

-Ekr

On Thu, Sep 26, 2019 at 3:48 PM Alissa = Cooper <alissa@cooperw.in> wrote:
Hi all,

The review period for this charter is a little longer than usual since = this is a proposal for a process-oriented WG that did not go through the = BOF process. As the charter text indicates, the idea of this WG is to = help streamline the consideration of process proposals and leverage the = WG chairs to help guide process discussions. Feedback is welcome.

Thanks,
Alissa Cooper
General Area AD


> On Sep 26, 2019, at 11:44 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> A new IETF WG has been proposed in the General Area. The IESG has = not made
> any determination yet. The following draft charter was submitted, = and is
> provided for informational purposes only. Please send your comments = to the
> IESG mailing list (iesg@ietf.org) by 2019-10-11.
>
> General Area Dispatch (gendispatch)
> = ----------------------------------------------------------------------- > Current status: Proposed WG
>
> Chairs:
>  Francesca Palombini <francesca.palombini@ericsson.com>
>  Pete Resnick <resnick@episteme.net>
>
> Assigned Area Director:
>  Alissa Cooper <alissa@cooperw.in>
>
> General Area Directors:
>  Alissa Cooper <alissa@cooperw.in>
>
> Mailing list:
>  Address: gendispatch@ietf.org
>  To subscribe:
>  Archive:
>
> Group page: https://datatracker.ietf.org/group/gendispatch/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/<= br class=3D""> >
> The GENDISPATCH working group is a DISPATCH-style working group = (see RFC
> 7957) chartered to consider proposals for new work in the GEN area, = including
> proposals for changes or improvements to the IETF process and = process
> documents. The working group is chartered to identify, or help = create, an
> appropriate venue for the work. The working group will not consider = any
> technical standardization work.
>
> Guiding principles for the proposed new work include:
>
> 1. Providing a clear problem statement, historical context, = motivation, and
> deliverables for the proposed new work.
>
> 2. Ensuring there has been adequate mailing list discussion = reflecting
> sufficient interest, individuals have expressed a willingness to = contribute
> (if appropriate given the subject matter of the proposal) and there = is WG
> consensus before new work is dispatched.
>
> 3. Looking for and identifying commonalities and overlap amongst = published or
> ongoing work in the GEN area, within the IESG, or within the IETF = LLC.
>
> Options for handling new work include:
>
> - Directing the work to an existing WG.
>
> - Developing a proposal for a BOF.
>
> - Developing a charter for a new WG.
>
> - Making recommendations that documents be AD-sponsored (which ADs = may or may
> not choose to follow).
>
> - Requesting that the the IESG or the IETF LLC consider taking up = the work.
>
> - Deferring the decision for the new work.
>
> - Rejecting the new work.
>
> If the group decides that a particular topic needs to be addressed = by a new
> WG, the normal IETF chartering process will be followed, including, = for
> instance, IETF-wide review of the proposed charter. Proposals for = large work
> efforts SHOULD lead to a BOF where the topic can be discussed in = front of the
> entire IETF community. Documents progressed as AD-sponsored would = typically
> include those that are extremely simple or make minor updates to = existing
> process documents.
>
> Proposed new work may be deferred in cases where the WG does not = have enough
> information for the chairs to determine consensus. New work may be = rejected
> in cases where there is not sufficient WG interest or the proposal = has been
> considered and rejected in the past, unless a substantially revised = proposal
> is put forth, including compelling new reasons for accepting the = work.
>
> A major objective of the GENDISPATCH WG is to provide timely, = clear
> dispositions of new efforts. Thus, where there is consensus to take = on new
> work, the WG will strive to quickly find a home for it. While most = new work
> in the GEN area is expected to be considered in the GENDISPATCH = working
> group, there may be times where that is not appropriate. At the = discretion of
> the GEN AD, new efforts may follow other paths. For example, work = may go
> directly to a BOF, may be initiated in other working groups when it = clearly
> belongs in that group, or may be directly AD-sponsored.
>
> Another major objective of the GENDISPATCH WG is to streamline how = the IETF
> community considers process improvements. Community discussions = about process
> suggestions that begin on other mailing lists, including ietf@ietf.org, will
> be redirected to the GENDISPATCH mailing list where they will be = facilitated
> by the WG chairs. Proponents of process improvements will be = encouraged to
> craft concrete proposals for discussion on the GENDISPATCH mailing = list, with
> the goal of producing a concrete outcome in bounded time. Direct = requests to
> the IESG may also, after proper consideration, be redirected to the = WG. For
> proposals to be considered by the WG they will be expected to meet = guiding
> principle #1 above.
>
> The existence of this working group does not change the IESG's
> responsibilities as described in RFC 3710. Work related to the IAB, = IRTF, and
> RFC Editor processes is out of scope.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce


= --Apple-Mail=_350CF455-D409-4383-A9D7-1AC8FD43FB31-- From nobody Fri Oct 4 10:22:41 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1D120143; Fri, 4 Oct 2019 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=bQLvzBQF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jL0HLZ9s 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 et7QTrS8bxhQ; Fri, 4 Oct 2019 10:22:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5DD1208D9; Fri, 4 Oct 2019 10:22:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6D2D321E50; Fri, 4 Oct 2019 13:22:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 04 Oct 2019 13:22:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=x SGWTZLlBizNmpa92l7jbiHQt5FlJhEN3RW1qxv728E=; b=bQLvzBQFIh0dKNSrD fPZiYVIaOumMYAqkzxL3Niu1GK5RsEKQR/rh/HVCHqwThj7B1exnSkkTW4NLoD6D 2vMTcZ8kYcpzxt4M8LflF9IZG8C1BaTdklkbl20Z0NmVpzXKB9iRE2DHxZG5Qj/E NDUWdnhd47fa8GQCTRpF6zM2UXBRbW2mmPOplpW9nl50HIk7PdTesN81HPXJrNcN JrhzYmQuymihvT8r7KWFyzmGVJdOOdNE+qXcjqkM9EzqUVBbjVVVTXLZD6wkJ54F AVDAZymfNIIpvE6xBLvtC3JeRZ6MBBRREYBrGB0aNauNyhoXjfRE31W/T87mIzx7 pO1aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=xSGWTZLlBizNmpa92l7jbiHQt5FlJhEN3RW1qxv72 8E=; b=jL0HLZ9s2PAdkY8BHPQvg9HAwwsisWMLnA+cO+Dye87f/VFbva2mNGF3o eZDM3APRio/mVHRRG6BP0NS63LT5we/q789O8fliUZS3SQjBam2/Lv8LV/eRclYs IxauZ8xTp1sH9RkL9Gd8j3A4S/2PD+k0GIPYgZEw4nKlbAkajTYSkdEOAw4pIvgB n83x2jPRvHKsE0mn/3tCWSQ72dziCHXvORykKDEu98vChml3jf4ky0gzUm3udA8P 5hN21XkurOLBtKr6CNTOoZY3vRhtA18ySgixA3xihwH9GqnpgqT1aPZZTU7rmMeF i5tz6zP1WaQq8aE5kVIRyHtIXeuIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrhedugddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepud dtkedrhedurddutddurdelkeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgr segtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id EE0DAD6005D; Fri, 4 Oct 2019 13:22:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <0D7F3F61-9789-41B5-B41D-65BD31353EB2@sn3rd.com> Date: Fri, 4 Oct 2019 13:22:30 -0400 Cc: gendispatch@ietf.org, IETF discussion list Content-Transfer-Encoding: quoted-printable Message-Id: <796BC62F-1CA7-4FDC-AC0A-E6C24C4A7595@cooperw.in> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <1ED85E0F-0CB2-450F-8D55-AA6D2027D72E@sn3rd.com> <0D7F3F61-9789-41B5-B41D-65BD31353EB2@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 17:22:34 -0000 Hi Sean, > On Oct 1, 2019, at 1:47 PM, Sean Turner wrote: >=20 > apologies for the double send. >=20 >> On Oct 1, 2019, at 16:30, Sean Turner wrote: >>=20 >> I am in favor of this proposal. One question below: >>=20 >>> On Sep 26, 2019, at 23:44, The IESG wrote: >>>=20 >>> f the group decides that a particular topic needs to be addressed by = a new >>> WG, the normal IETF chartering process will be followed, including, = for >>> instance, IETF-wide review of the proposed charter. Proposals for = large work >>> efforts SHOULD lead to a BOF where the topic can be discussed in = front of the >>> entire IETF community. Documents progressed as AD-sponsored would = typically >>> include those that are extremely simple or make minor updates to = existing >>> process documents. >>=20 >> Is the AD in this case always the IETF Chair? I am somewhat = concerned about increasing the workload of the IETF Chair when the I-D = might doing something so minor (and possibly noncontroversial) that any = AD could sponsor the I-D. It need not be. To take a recent example, RFC 8318 was a process doc = that was AD-sponsored by an ART AD. Thanks, Alissa >>=20 >>=20 >> spt >=20 From nobody Sat Oct 5 23:34:24 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8C2120047; Sat, 5 Oct 2019 23:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 WxeqSaNvnGmd; Sat, 5 Oct 2019 23:34:18 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 56849120020; Sat, 5 Oct 2019 23:34:18 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BEDB3F5A41C3050B30A8; Sun, 6 Oct 2019 07:34:16 +0100 (IST) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 6 Oct 2019 07:34:16 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.89]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0439.000; Sun, 6 Oct 2019 14:34:13 +0800 From: "Roni Even (A)" To: Alissa Cooper , IETF CC: "gendispatch@ietf.org" Thread-Topic: WG Review: General Area Dispatch (gendispatch) Thread-Index: AQHVdLx8VIhAjaF7HUiTnWGfF6YetadNNXiw Date: Sun, 6 Oct 2019 06:34:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D79C06@DGGEMM506-MBX.china.huawei.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 06:34:22 -0000 Hi, I think this is a good idea.=20 I hope it will help with better convergence on some of the topic discussed = on the discuss mailing list by having this WG chairs shepherding the discus= sion. I am wondering if this dispatch WG will require a draft in order to start a= discussion on a new topic. It will probably require the WG chairs to be mo= re active with bringing new relevant items to the WG Roni Even -----Original Message----- From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Friday, September 27, 2019 1:48 AM To: IETF Cc: gendispatch@ietf.org Subject: Re: WG Review: General Area Dispatch (gendispatch) Hi all, The review period for this charter is a little longer than usual since this= is a proposal for a process-oriented WG that did not go through the BOF pr= ocess. As the charter text indicates, the idea of this WG is to help stream= line the consideration of process proposals and leverage the WG chairs to h= elp guide process discussions. Feedback is welcome. Thanks, Alissa Cooper General Area AD > On Sep 26, 2019, at 11:44 PM, The IESG wrote: >=20 > A new IETF WG has been proposed in the General Area. The IESG has not=20 > made any determination yet. The following draft charter was submitted,=20 > and is provided for informational purposes only. Please send your=20 > comments to the IESG mailing list (iesg@ietf.org) by 2019-10-11. >=20 > General Area Dispatch (gendispatch) > ---------------------------------------------------------------------- > - > Current status: Proposed WG >=20 > Chairs: > Francesca Palombini > Pete Resnick >=20 > Assigned Area Director: > Alissa Cooper >=20 > General Area Directors: > Alissa Cooper >=20 > Mailing list: > Address: gendispatch@ietf.org > To subscribe: > Archive: >=20 > Group page: https://datatracker.ietf.org/group/gendispatch/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ >=20 > The GENDISPATCH working group is a DISPATCH-style working group (see=20 > RFC > 7957) chartered to consider proposals for new work in the GEN area,=20 > including proposals for changes or improvements to the IETF process=20 > and process documents. The working group is chartered to identify, or=20 > help create, an appropriate venue for the work. The working group will=20 > not consider any technical standardization work. >=20 > Guiding principles for the proposed new work include: >=20 > 1. Providing a clear problem statement, historical context,=20 > motivation, and deliverables for the proposed new work. >=20 > 2. Ensuring there has been adequate mailing list discussion reflecting=20 > sufficient interest, individuals have expressed a willingness to=20 > contribute (if appropriate given the subject matter of the proposal)=20 > and there is WG consensus before new work is dispatched. >=20 > 3. Looking for and identifying commonalities and overlap amongst=20 > published or ongoing work in the GEN area, within the IESG, or within the= IETF LLC. >=20 > Options for handling new work include: >=20 > - Directing the work to an existing WG. >=20 > - Developing a proposal for a BOF. >=20 > - Developing a charter for a new WG. >=20 > - Making recommendations that documents be AD-sponsored (which ADs may=20 > or may not choose to follow). >=20 > - Requesting that the the IESG or the IETF LLC consider taking up the wor= k. >=20 > - Deferring the decision for the new work. >=20 > - Rejecting the new work. >=20 > If the group decides that a particular topic needs to be addressed by=20 > a new WG, the normal IETF chartering process will be followed,=20 > including, for instance, IETF-wide review of the proposed charter.=20 > Proposals for large work efforts SHOULD lead to a BOF where the topic=20 > can be discussed in front of the entire IETF community. Documents=20 > progressed as AD-sponsored would typically include those that are=20 > extremely simple or make minor updates to existing process documents. >=20 > Proposed new work may be deferred in cases where the WG does not have=20 > enough information for the chairs to determine consensus. New work may=20 > be rejected in cases where there is not sufficient WG interest or the=20 > proposal has been considered and rejected in the past, unless a=20 > substantially revised proposal is put forth, including compelling new rea= sons for accepting the work. >=20 > A major objective of the GENDISPATCH WG is to provide timely, clear=20 > dispositions of new efforts. Thus, where there is consensus to take on=20 > new work, the WG will strive to quickly find a home for it. While most=20 > new work in the GEN area is expected to be considered in the=20 > GENDISPATCH working group, there may be times where that is not=20 > appropriate. At the discretion of the GEN AD, new efforts may follow=20 > other paths. For example, work may go directly to a BOF, may be=20 > initiated in other working groups when it clearly belongs in that group, = or may be directly AD-sponsored. >=20 > Another major objective of the GENDISPATCH WG is to streamline how the=20 > IETF community considers process improvements. Community discussions=20 > about process suggestions that begin on other mailing lists, including=20 > ietf@ietf.org, will be redirected to the GENDISPATCH mailing list=20 > where they will be facilitated by the WG chairs. Proponents of process=20 > improvements will be encouraged to craft concrete proposals for=20 > discussion on the GENDISPATCH mailing list, with the goal of producing=20 > a concrete outcome in bounded time. Direct requests to the IESG may=20 > also, after proper consideration, be redirected to the WG. For=20 > proposals to be considered by the WG they will be expected to meet guidin= g principle #1 above. >=20 > The existence of this working group does not change the IESG's=20 > responsibilities as described in RFC 3710. Work related to the IAB,=20 > IRTF, and RFC Editor processes is out of scope. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Mon Oct 7 05:50:47 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09F120018; Mon, 7 Oct 2019 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=rtJzvarw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AX1l8aCT 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 9Nq5AHLdACm2; Mon, 7 Oct 2019 05:50:41 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CE6120020; Mon, 7 Oct 2019 05:50:41 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DDEC921AD0; Mon, 7 Oct 2019 08:50:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 07 Oct 2019 08:50:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=4 TPDx9B7u3eMvymjHJSL2Wic5u1PkD4W76PC6FPzgVg=; b=rtJzvarwy9Evn/+/1 bt6ddYUNytStzgUXLHM88uiE3ALT58PKDfOrX3tKcQeR2iHGUGFsNeqgC44c/QN2 GILO7MdL0WB1kZkHS8v3cNP6IppnUCisi7ja5jxMQUkXy2fsf5IXme+IBsKHFl0f CWxXYRaxGWYNzp1Cza9uyW+wxQBb551vQd4NWMr5OhJuw5kb/pzv4Dc+mduXRQd2 w5BIxu/rH3L7cN6kwr0538MwFjDMPnClFzZ+hcNFjTrKueiQNJ1/N39wnebwVk7F yDrlxPBOw8lZ5zkVdXPeIkkwxHV5Na0Mm0w0+9KKSQU1NtzwUrwD9AewE9z8TmCn vCebw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=4TPDx9B7u3eMvymjHJSL2Wic5u1PkD4W76PC6FPzg Vg=; b=AX1l8aCTgtTz8A/lx5b0w11KOHB2kPD3+9MxxAEOwtkB9tCKRtsEpjI/8 cRwGW7liIh8m8QWcRnd1Ih1EBTfQvP6dryQCf508YBVV14kerqyqmH/4D0IASgcB l+mdx2fXOijirbjIMYhbgZ8ggrIYgfB50TOTLFLi/W9Ms6/kMCSMWDpq+LjgvQRE PPDfeY6FvslgfL+jTxS9tH7RghXOxsQyqMTpUZYmfCRJvTYF3oL9aQ4Yi5S4k7M3 gok48nCU4lmvfnUj17SS+YKKMfZG+FWGe4jHietNN3PlzeH+CAFfIRwmFz8oCbuL S2s9KO4nDvkTm08r3g3aLhHbe02Qw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheejgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id C87D6D6005B; Mon, 7 Oct 2019 08:50:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D79C06@DGGEMM506-MBX.china.huawei.com> Date: Mon, 7 Oct 2019 08:50:38 -0400 Cc: IETF , "gendispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3F18BEE5-A5F1-4CE1-AEAF-D5B8411D555B@cooperw.in> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD23D79C06@DGGEMM506-MBX.china.huawei.com> To: "Roni Even (A)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 12:50:45 -0000 Hi Roni, > On Oct 6, 2019, at 2:34 AM, Roni Even (A) = wrote: >=20 > Hi, > I think this is a good idea.=20 > I hope it will help with better convergence on some of the topic = discussed on the discuss mailing list by having this WG chairs = shepherding the discussion. > I am wondering if this dispatch WG will require a draft in order to = start a discussion on a new topic. That seems like a good practice for the chairs to adopt at least for = actual meeting presentation slots. Might be a bit of a high bar for = mailing list discussion though. Alissa > It will probably require the WG chairs to be more active with bringing = new relevant items to the WG >=20 > Roni Even >=20 > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Friday, September 27, 2019 1:48 AM > To: IETF > Cc: gendispatch@ietf.org > Subject: Re: WG Review: General Area Dispatch (gendispatch) >=20 > Hi all, >=20 > The review period for this charter is a little longer than usual since = this is a proposal for a process-oriented WG that did not go through the = BOF process. As the charter text indicates, the idea of this WG is to = help streamline the consideration of process proposals and leverage the = WG chairs to help guide process discussions. Feedback is welcome. >=20 > Thanks, > Alissa Cooper > General Area AD >=20 >=20 >> On Sep 26, 2019, at 11:44 PM, The IESG = wrote: >>=20 >> A new IETF WG has been proposed in the General Area. The IESG has not=20= >> made any determination yet. The following draft charter was = submitted,=20 >> and is provided for informational purposes only. Please send your=20 >> comments to the IESG mailing list (iesg@ietf.org) by 2019-10-11. >>=20 >> General Area Dispatch (gendispatch) >> = ---------------------------------------------------------------------- >> - >> Current status: Proposed WG >>=20 >> Chairs: >> Francesca Palombini >> Pete Resnick >>=20 >> Assigned Area Director: >> Alissa Cooper >>=20 >> General Area Directors: >> Alissa Cooper >>=20 >> Mailing list: >> Address: gendispatch@ietf.org >> To subscribe: >> Archive: >>=20 >> Group page: https://datatracker.ietf.org/group/gendispatch/ >>=20 >> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ >>=20 >> The GENDISPATCH working group is a DISPATCH-style working group (see=20= >> RFC >> 7957) chartered to consider proposals for new work in the GEN area,=20= >> including proposals for changes or improvements to the IETF process=20= >> and process documents. The working group is chartered to identify, or=20= >> help create, an appropriate venue for the work. The working group = will=20 >> not consider any technical standardization work. >>=20 >> Guiding principles for the proposed new work include: >>=20 >> 1. Providing a clear problem statement, historical context,=20 >> motivation, and deliverables for the proposed new work. >>=20 >> 2. Ensuring there has been adequate mailing list discussion = reflecting=20 >> sufficient interest, individuals have expressed a willingness to=20 >> contribute (if appropriate given the subject matter of the proposal)=20= >> and there is WG consensus before new work is dispatched. >>=20 >> 3. Looking for and identifying commonalities and overlap amongst=20 >> published or ongoing work in the GEN area, within the IESG, or within = the IETF LLC. >>=20 >> Options for handling new work include: >>=20 >> - Directing the work to an existing WG. >>=20 >> - Developing a proposal for a BOF. >>=20 >> - Developing a charter for a new WG. >>=20 >> - Making recommendations that documents be AD-sponsored (which ADs = may=20 >> or may not choose to follow). >>=20 >> - Requesting that the the IESG or the IETF LLC consider taking up the = work. >>=20 >> - Deferring the decision for the new work. >>=20 >> - Rejecting the new work. >>=20 >> If the group decides that a particular topic needs to be addressed by=20= >> a new WG, the normal IETF chartering process will be followed,=20 >> including, for instance, IETF-wide review of the proposed charter.=20 >> Proposals for large work efforts SHOULD lead to a BOF where the topic=20= >> can be discussed in front of the entire IETF community. Documents=20 >> progressed as AD-sponsored would typically include those that are=20 >> extremely simple or make minor updates to existing process documents. >>=20 >> Proposed new work may be deferred in cases where the WG does not have=20= >> enough information for the chairs to determine consensus. New work = may=20 >> be rejected in cases where there is not sufficient WG interest or the=20= >> proposal has been considered and rejected in the past, unless a=20 >> substantially revised proposal is put forth, including compelling new = reasons for accepting the work. >>=20 >> A major objective of the GENDISPATCH WG is to provide timely, clear=20= >> dispositions of new efforts. Thus, where there is consensus to take = on=20 >> new work, the WG will strive to quickly find a home for it. While = most=20 >> new work in the GEN area is expected to be considered in the=20 >> GENDISPATCH working group, there may be times where that is not=20 >> appropriate. At the discretion of the GEN AD, new efforts may follow=20= >> other paths. For example, work may go directly to a BOF, may be=20 >> initiated in other working groups when it clearly belongs in that = group, or may be directly AD-sponsored. >>=20 >> Another major objective of the GENDISPATCH WG is to streamline how = the=20 >> IETF community considers process improvements. Community discussions=20= >> about process suggestions that begin on other mailing lists, = including=20 >> ietf@ietf.org, will be redirected to the GENDISPATCH mailing list=20 >> where they will be facilitated by the WG chairs. Proponents of = process=20 >> improvements will be encouraged to craft concrete proposals for=20 >> discussion on the GENDISPATCH mailing list, with the goal of = producing=20 >> a concrete outcome in bounded time. Direct requests to the IESG may=20= >> also, after proper consideration, be redirected to the WG. For=20 >> proposals to be considered by the WG they will be expected to meet = guiding principle #1 above. >>=20 >> The existence of this working group does not change the IESG's=20 >> responsibilities as described in RFC 3710. Work related to the IAB,=20= >> IRTF, and RFC Editor processes is out of scope. >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From nobody Mon Oct 7 06:02:09 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775A5120096; Mon, 7 Oct 2019 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 45DevtIYKOGl; Mon, 7 Oct 2019 06:01:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CD337120020; Mon, 7 Oct 2019 06:01:57 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EA76E5748927A4136F44; Mon, 7 Oct 2019 14:01:55 +0100 (IST) Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Oct 2019 14:01:55 +0100 Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 7 Oct 2019 14:01:55 +0100 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 7 Oct 2019 14:01:55 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.89]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Mon, 7 Oct 2019 21:01:49 +0800 From: "Roni Even (A)" To: Alissa Cooper CC: IETF , "gendispatch@ietf.org" Thread-Topic: WG Review: General Area Dispatch (gendispatch) Thread-Index: AQHVdLx8VIhAjaF7HUiTnWGfF6YetadNNXiwgAF2lQCAAIcaQA== Date: Mon, 7 Oct 2019 13:01:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D79EF8@DGGEMM506-MBX.china.huawei.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD23D79C06@DGGEMM506-MBX.china.huawei.com> <3F18BEE5-A5F1-4CE1-AEAF-D5B8411D555B@cooperw.in> In-Reply-To: <3F18BEE5-A5F1-4CE1-AEAF-D5B8411D555B@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 13:02:01 -0000 Hi Alissa What I meant that since this WG is chartered to address "non-technical" top= ics, where everyone has an opinion, my observation is that the discussions= are not focused, multiple threads start to appear on the mailing list maki= ng it difficult to follow.=20 I think that it will be good if this new WG chairs (or someone appointed by= them) will try to bring such a discussion to be structured by summarizing = the discussion points and the views and list the open discussion points to = help with convergence (similar to meeting notes). Roni > On Oct 6, 2019, at 2:34 AM, Roni Even (A) wrote: >=20 > Hi, > I think this is a good idea.=20 > I hope it will help with better convergence on some of the topic discusse= d on the discuss mailing list by having this WG chairs shepherding the disc= ussion. > I am wondering if this dispatch WG will require a draft in order to start= a discussion on a new topic. That seems like a good practice for the chairs to adopt at least for actual= meeting presentation slots. Might be a bit of a high bar for mailing list = discussion though. Alissa > It will probably require the WG chairs to be more active with bringing=20 > new relevant items to the WG >=20 > Roni Even >=20 > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Friday, September 27, 2019 1:48 AM > To: IETF > Cc: gendispatch@ietf.org > Subject: Re: WG Review: General Area Dispatch (gendispatch) >=20 > Hi all, >=20 > The review period for this charter is a little longer than usual since th= is is a proposal for a process-oriented WG that did not go through the BOF = process. As the charter text indicates, the idea of this WG is to help stre= amline the consideration of process proposals and leverage the WG chairs to= help guide process discussions. Feedback is welcome. >=20 > Thanks, > Alissa Cooper > General Area AD >=20 >=20 >> On Sep 26, 2019, at 11:44 PM, The IESG wrote: >>=20 >> A new IETF WG has been proposed in the General Area. The IESG has not=20 >> made any determination yet. The following draft charter was=20 >> submitted, and is provided for informational purposes only. Please=20 >> send your comments to the IESG mailing list (iesg@ietf.org) by 2019-10-1= 1. >>=20 >> General Area Dispatch (gendispatch) >> --------------------------------------------------------------------- >> - >> - >> Current status: Proposed WG >>=20 >> Chairs: >> Francesca Palombini >> Pete Resnick >>=20 >> Assigned Area Director: >> Alissa Cooper >>=20 >> General Area Directors: >> Alissa Cooper >>=20 >> Mailing list: >> Address: gendispatch@ietf.org >> To subscribe: >> Archive: >>=20 >> Group page: https://datatracker.ietf.org/group/gendispatch/ >>=20 >> Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ >>=20 >> The GENDISPATCH working group is a DISPATCH-style working group (see=20 >> RFC >> 7957) chartered to consider proposals for new work in the GEN area,=20 >> including proposals for changes or improvements to the IETF process=20 >> and process documents. The working group is chartered to identify, or=20 >> help create, an appropriate venue for the work. The working group=20 >> will not consider any technical standardization work. >>=20 >> Guiding principles for the proposed new work include: >>=20 >> 1. Providing a clear problem statement, historical context,=20 >> motivation, and deliverables for the proposed new work. >>=20 >> 2. Ensuring there has been adequate mailing list discussion=20 >> reflecting sufficient interest, individuals have expressed a=20 >> willingness to contribute (if appropriate given the subject matter of=20 >> the proposal) and there is WG consensus before new work is dispatched. >>=20 >> 3. Looking for and identifying commonalities and overlap amongst=20 >> published or ongoing work in the GEN area, within the IESG, or within th= e IETF LLC. >>=20 >> Options for handling new work include: >>=20 >> - Directing the work to an existing WG. >>=20 >> - Developing a proposal for a BOF. >>=20 >> - Developing a charter for a new WG. >>=20 >> - Making recommendations that documents be AD-sponsored (which ADs=20 >> may or may not choose to follow). >>=20 >> - Requesting that the the IESG or the IETF LLC consider taking up the wo= rk. >>=20 >> - Deferring the decision for the new work. >>=20 >> - Rejecting the new work. >>=20 >> If the group decides that a particular topic needs to be addressed by=20 >> a new WG, the normal IETF chartering process will be followed,=20 >> including, for instance, IETF-wide review of the proposed charter. >> Proposals for large work efforts SHOULD lead to a BOF where the topic=20 >> can be discussed in front of the entire IETF community. Documents=20 >> progressed as AD-sponsored would typically include those that are=20 >> extremely simple or make minor updates to existing process documents. >>=20 >> Proposed new work may be deferred in cases where the WG does not have=20 >> enough information for the chairs to determine consensus. New work=20 >> may be rejected in cases where there is not sufficient WG interest or=20 >> the proposal has been considered and rejected in the past, unless a=20 >> substantially revised proposal is put forth, including compelling new re= asons for accepting the work. >>=20 >> A major objective of the GENDISPATCH WG is to provide timely, clear=20 >> dispositions of new efforts. Thus, where there is consensus to take=20 >> on new work, the WG will strive to quickly find a home for it. While=20 >> most new work in the GEN area is expected to be considered in the=20 >> GENDISPATCH working group, there may be times where that is not=20 >> appropriate. At the discretion of the GEN AD, new efforts may follow=20 >> other paths. For example, work may go directly to a BOF, may be=20 >> initiated in other working groups when it clearly belongs in that group,= or may be directly AD-sponsored. >>=20 >> Another major objective of the GENDISPATCH WG is to streamline how=20 >> the IETF community considers process improvements. Community=20 >> discussions about process suggestions that begin on other mailing=20 >> lists, including ietf@ietf.org, will be redirected to the GENDISPATCH=20 >> mailing list where they will be facilitated by the WG chairs.=20 >> Proponents of process improvements will be encouraged to craft=20 >> concrete proposals for discussion on the GENDISPATCH mailing list,=20 >> with the goal of producing a concrete outcome in bounded time. Direct=20 >> requests to the IESG may also, after proper consideration, be=20 >> redirected to the WG. For proposals to be considered by the WG they will= be expected to meet guiding principle #1 above. >>=20 >> The existence of this working group does not change the IESG's=20 >> responsibilities as described in RFC 3710. Work related to the IAB,=20 >> IRTF, and RFC Editor processes is out of scope. >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From nobody Tue Oct 8 11:57:33 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3A1200D6; Tue, 8 Oct 2019 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 PiVG7zI0YYR6; Tue, 8 Oct 2019 11:57:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CC4991200B9; Tue, 8 Oct 2019 11:57:29 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x98IvRSr076865 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Oct 2019 13:57:28 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570561049; bh=EEQbjGYsOx/E7nUk8kLKK5O7d/Zn2IantxOkYlGavMw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZQZ4EDkrhS8GsYZWgeHJJgmhO2QTaQ66IEWSnarKavSdGBF75IEd1SlGp0xxfboE4 8+5UYEhOKsVfNLimkQ1JGpDpFti+/+zIccZ0u5+EWYofcO2oiN9Rols3D8HFf+5mCl usYsx33WcOvxV2rHDBxsn7UBP8kOdI/M2fOp/Nlg= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> Date: Tue, 8 Oct 2019 13:57:22 -0500 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> To: ietf@ietf.org, The IESG X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 18:57:32 -0000 I=E2=80=99m trying to think about GENDISPATCH from the perspective of = DISPATCH in the ART Area. I=E2=80=99m sort of on the fence about whether = this is a good idea. So, I have questions: DISPATCH was originally formed because the RAI (now ART) area had a = firehose of new proposals, mostly related to SIP and the surrounding = protocol halo. Many of these proposals were not of general interest, or = came in the form of a solution rather than a problem. DISPATCH was = formed to try to make sense of that. DISPATCH seems to work best when = there are a steady stream of new work proposals; when that stream slows = down we sometimes have trouble getting people to pay attention. Note = that =E2=80=9Csteady stream of new work=E2=80=9D is not the same as =E2=80= =9Ca steady stream of discussion about a few topics=E2=80=9D. Do we have that same problem for GEN proposals? I think there are = issues, but they are probably different issues. What is the problem to = be solved? At the risk of strawman-ing: If the problem is mainly that GEN issues = tend to eat the IESG list, then a separate mailing list could be enough. = Maybe the idea is mainly to have chairs responsible for discussion = wrangling? If so, then a more conventional =E2=80=9CGenArea=E2=80=9D = working group might do the trick. Another difference is that while DISPATCH is mainly interesting to = people in the ART Area, we can expect GENDISPATCH to draw from all = areas. We try not to let DISPATCH conflict with other ART meetings. How = do you deconflict GENDISPATCH without it turning into another plenary or = a standing BoF? Thanks, Ben. > On Sep 26, 2019, at 5:44 PM, The IESG wrote: >=20 > A new IETF WG has been proposed in the General Area. The IESG has not = made > any determination yet. The following draft charter was submitted, and = is > provided for informational purposes only. Please send your comments to = the > IESG mailing list (iesg@ietf.org) by 2019-10-11. >=20 > General Area Dispatch (gendispatch) > = ----------------------------------------------------------------------- > Current status: Proposed WG >=20 > Chairs: > Francesca Palombini > Pete Resnick >=20 > Assigned Area Director: > Alissa Cooper >=20 > General Area Directors: > Alissa Cooper >=20 > Mailing list: > Address: gendispatch@ietf.org > To subscribe: > Archive: >=20 > Group page: https://datatracker.ietf.org/group/gendispatch/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ >=20 > The GENDISPATCH working group is a DISPATCH-style working group (see = RFC > 7957) chartered to consider proposals for new work in the GEN area, = including > proposals for changes or improvements to the IETF process and process > documents. The working group is chartered to identify, or help create, = an > appropriate venue for the work. The working group will not consider = any > technical standardization work. >=20 > Guiding principles for the proposed new work include: >=20 > 1. Providing a clear problem statement, historical context, = motivation, and > deliverables for the proposed new work. >=20 > 2. Ensuring there has been adequate mailing list discussion reflecting > sufficient interest, individuals have expressed a willingness to = contribute > (if appropriate given the subject matter of the proposal) and there is = WG > consensus before new work is dispatched. >=20 > 3. Looking for and identifying commonalities and overlap amongst = published or > ongoing work in the GEN area, within the IESG, or within the IETF LLC. >=20 > Options for handling new work include: >=20 > - Directing the work to an existing WG. >=20 > - Developing a proposal for a BOF. >=20 > - Developing a charter for a new WG. >=20 > - Making recommendations that documents be AD-sponsored (which ADs may = or may > not choose to follow). >=20 > - Requesting that the the IESG or the IETF LLC consider taking up the = work. >=20 > - Deferring the decision for the new work. >=20 > - Rejecting the new work. >=20 > If the group decides that a particular topic needs to be addressed by = a new > WG, the normal IETF chartering process will be followed, including, = for > instance, IETF-wide review of the proposed charter. Proposals for = large work > efforts SHOULD lead to a BOF where the topic can be discussed in front = of the > entire IETF community. Documents progressed as AD-sponsored would = typically > include those that are extremely simple or make minor updates to = existing > process documents. >=20 > Proposed new work may be deferred in cases where the WG does not have = enough > information for the chairs to determine consensus. New work may be = rejected > in cases where there is not sufficient WG interest or the proposal has = been > considered and rejected in the past, unless a substantially revised = proposal > is put forth, including compelling new reasons for accepting the work. >=20 > A major objective of the GENDISPATCH WG is to provide timely, clear > dispositions of new efforts. Thus, where there is consensus to take on = new > work, the WG will strive to quickly find a home for it. While most new = work > in the GEN area is expected to be considered in the GENDISPATCH = working > group, there may be times where that is not appropriate. At the = discretion of > the GEN AD, new efforts may follow other paths. For example, work may = go > directly to a BOF, may be initiated in other working groups when it = clearly > belongs in that group, or may be directly AD-sponsored. >=20 > Another major objective of the GENDISPATCH WG is to streamline how the = IETF > community considers process improvements. Community discussions about = process > suggestions that begin on other mailing lists, including = ietf@ietf.org, will > be redirected to the GENDISPATCH mailing list where they will be = facilitated > by the WG chairs. Proponents of process improvements will be = encouraged to > craft concrete proposals for discussion on the GENDISPATCH mailing = list, with > the goal of producing a concrete outcome in bounded time. Direct = requests to > the IESG may also, after proper consideration, be redirected to the = WG. For > proposals to be considered by the WG they will be expected to meet = guiding > principle #1 above. >=20 > The existence of this working group does not change the IESG's > responsibilities as described in RFC 3710. Work related to the IAB, = IRTF, and > RFC Editor processes is out of scope. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Tue Oct 8 12:18:52 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61A11200B9; Tue, 8 Oct 2019 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 eQgQT7YlYxjM; Tue, 8 Oct 2019 12:18:31 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 46F021200D6; Tue, 8 Oct 2019 12:18:31 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id w12so38938191iol.11; Tue, 08 Oct 2019 12:18:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gZcVtY+KlWoimrd2uTVTyYDF/DcEa775yKVJpqws6dw=; b=MUgn/T5KYlUaPQMkOsbHuJ8pFEmTJSnqs+Up3Xx5xi1lc/vcCJHUEtYA1XssfdHEWS /+SseIoXha9t/ykFzP0NsGOGdWmDGAJKnbMGhL6hHJdcT7aHBK5iE6N46SAPFITWrHs/ wt4FsiXWMD06kcMQWyOqJ3b7wth7+wIvFHf/tF6mdPbBzc/eslDAzpKIR6f/HuVYr/uq wsEawgmvo4NJlrkjZDLb3z0lpqztJ7skSohNIWP1irVMlZYj25MAJzPIbFtw5Oi6t7yS uiEaeOOw7YYmxl44lnCg+ocfMXeRlqLcqXXWWWOoAf3lpqXi1d5GFuQMl04brKf8MBuE /aag== X-Gm-Message-State: APjAAAUYevZ8NHeqEl0z1eQkVgfW/BoqIVi8B7KPT5+m46VWz5DItmQ2 2ou3kmMuQCkPSF+DTb9Q6Vie4AL0b/GkKVAr8GCms+UcJlo= X-Google-Smtp-Source: APXvYqzxuWZiVsD0+A0lJz9+7uPJv9vLQgfe673Ec7OdSYU28fGGDfc/jlYwT/9iuqSmtMt+A8lsnUxMYi1/3adcXQs= X-Received: by 2002:a02:a15b:: with SMTP id m27mr5498266jah.59.1570562310064; Tue, 08 Oct 2019 12:18:30 -0700 (PDT) MIME-Version: 1.0 References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> In-Reply-To: <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> From: Barry Leiba Date: Tue, 8 Oct 2019 21:18:18 +0200 Message-ID: To: Ben Campbell Cc: IETF discussion list , The IESG , gendispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 19:18:35 -0000 > At the risk of strawman-ing: If the problem is mainly that GEN issues > tend to eat the IESG list, then a separate mailing list could be > enough. Maybe the idea is mainly to have chairs responsible for > discussion wrangling? If so, then a more conventional =E2=80=9CGenArea=E2= =80=9D working > group might do the trick. I don't think it's that they "eat the IESG list" so much as that they "eat the IETF list". And not in the sense that they monopolize the list, but that that particular list isn't sufficiently focused to give process issues proper consideration and determine what the right way to handle them is. From my PoV, the advantage of a DISPATCH-like group, rather than an unfocused area group, is that the former is assigned the task of considering what's being discussed/proposed and figuring out how best to address it... rather than to just keep discussing it to no conclusion. > Another difference is that while DISPATCH is mainly interesting to > people in the ART Area, we can expect GENDISPATCH to draw from all > areas. We try not to let DISPATCH conflict with other ART meetings. How > do you deconflict GENDISPATCH without it turning into another plenary > or a standing BoF? This is always an issue with Gen Area BoFs and WGs, and this will be no different. I think the bottom line is that there'll be a set of people who will want to participate regularly, and we'll try to accommodate that... there'll be people who want to parachute in for certain topics, and we'll do what we can to accommodate that, realizing that it's harder... and there'll be a lot of people who won't want to have anything to do with it until a proposal is at a stage where they strongly support it or object to it, and there's little we can do to accommodate that. It is what it is, but it's no different than if we just charter Gen Area WGs without a DISPATCH-like start. No? Barry From nobody Tue Oct 8 12:48:41 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADE120033; Tue, 8 Oct 2019 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 qLc-nJWIs95e; Tue, 8 Oct 2019 12:48:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 14957120013; Tue, 8 Oct 2019 12:48:38 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x98JmYGB086103 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Oct 2019 14:48:35 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570564116; bh=ucTZodvX/mYbVPNMZmkvuXIwukPwkz33Ktx+zGBZRk8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B1kgfkTpQfrGxw09RNlqeVupTKgtJjGkhnCAFgDZhaesxF+fCcBJJl0mNhwBkJxZC pCwpNzdOWJYxGk2sqj51TqXyYXAOWuMRg1eP7yqIfeZk0G6JaTkZggYgpTHoXf5ZhA h+jgjfY4CwBjG845iY5kYtrrQmqCwjheNMS6gPKM= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: Date: Tue, 8 Oct 2019 14:48:29 -0500 Cc: IETF discussion list , The IESG , gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> To: Barry Leiba X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 19:48:40 -0000 > On Oct 8, 2019, at 2:18 PM, Barry Leiba = wrote: >=20 >> At the risk of strawman-ing: If the problem is mainly that GEN issues >> tend to eat the IESG list, then a separate mailing list could be >> enough. Maybe the idea is mainly to have chairs responsible for >> discussion wrangling? If so, then a more conventional =E2=80=9CGenArea=E2= =80=9D working >> group might do the trick. >=20 > I don't think it's that they "eat the IESG list" so much as that they > "eat the IETF list=E2=80=9D. Oops, typo on my part. I meant the IETF list. > And not in the sense that they monopolize the > list, but that that particular list isn't sufficiently focused to give > process issues proper consideration and determine what the right way > to handle them is. =46rom my PoV, the advantage of a DISPATCH-like > group, rather than an unfocused area group, is that the former is > assigned the task of considering what's being discussed/proposed and > figuring out how best to address it... rather than to just keep > discussing it to no conclusion. Do you think writing a charter will really change people=E2=80=99s = behavior on that matter? I imagine most people on the IETF list would = like to come to a conclusion as it is. But as I think about this, it seems to me the main advantage of the wg = would be to have a home for discussion and some experienced chairs to = try to wrangle it. The original promise of DISPATCH was the ability to say =E2=80=9CNo, = this is not something appropriate for the IETF to work on right now due = to (reasons).=E2=80=9D My experience is that mainly happens when there = is insufficient interest in a proposal. Even then the proponents are = often unhappy with the result. It=E2=80=99s rare for DISPATCH[ to = conclude =E2=80=9CThere are so many opinions we are unlikely to reach = consensus=E2=80=9D. Unfortunately for GENDISPATCH, I think that will be = the most common show-stopper=E2=80=94and a GENDISPATCH conclusion to = that effect will not, by itself, stop such a discussion from continuing = to eat mailing lists. I suppose it=E2=80=99s possible that GENDISPATCH could say =E2=80=9CWe = probably can=E2=80=99t reach consensus on problem A, but maybe we can on = B an C; can people please put their energy into those now and fight = about A later?=E2=80=9D. >> Another difference is that while DISPATCH is mainly interesting to >> people in the ART Area, we can expect GENDISPATCH to draw from all >> areas. We try not to let DISPATCH conflict with other ART meetings. = How >> do you deconflict GENDISPATCH without it turning into another plenary >> or a standing BoF? >=20 > This is always an issue with Gen Area BoFs and WGs, and this will be > no different. I think the bottom line is that there'll be a set of > people who will want to participate regularly, and we'll try to > accommodate that... there'll be people who want to parachute in for > certain topics, and we'll do what we can to accommodate that, > realizing that it's harder... and there'll be a lot of people who > won't want to have anything to do with it until a proposal is at a > stage where they strongly support it or object to it, and there's > little we can do to accommodate that. It is what it is, but it's no > different than if we just charter Gen Area WGs without a DISPATCH-like > start. No? I agree that deconflicting a GenArea wg and a GenDispatch wg would be = essentially the same problem. In either case, both the =E2=80=9Cregular = set=E2=80=9D and the =E2=80=9Cparatrooper=E2=80=9D participants are = equally likely to participate in any other working group. Since = gendispatch would cover (I assume) more topics than a either a GEN bof = or =E2=80=9Cnormal" GEN wg, the deconflicting problem will be harder. = Plenary meetings would be a better comparison. Again, I=E2=80=99m not completely opposed, just on the fence. Ben. From nobody Tue Oct 8 15:07:15 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCEE120020; Tue, 8 Oct 2019 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=oGXIPRqX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m4xioOIp 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 NR9Nv73Vzsid; Tue, 8 Oct 2019 15:06:55 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF32A12007A; Tue, 8 Oct 2019 15:06:55 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 926186F7; Tue, 8 Oct 2019 18:06:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Oct 2019 18:06:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=i stqjyGsFkKHSY0NJUgnyO84qt+ZG/fxJ8tWu8OIPuk=; b=oGXIPRqXhhlEZr7cB Dv9ysAwMeCiwqmqHB3ZgXP7i0a/ahpwkNnux8zn+aX4HRaNCOTDFcg4cUPrAF9Dk VloEDVFzbWuun/dVfVNDB2JTlA5bi0VoTFA3ESeTpuFWD6Vqrb8Ps7E/C3FwA5cT yjA2DC8D1eQ03qHw8rcre/kCTjhrBhBQHGiafIz3N283yDiuoP8o2kK+/sX9tktZ 0bcrsWX4liZFfp6EwuxKLJpF4daNGAsw81i0bM+glEgcxgsFxNeS/O1KQ/QM/iHx PNNF38+SvclwPfV5IXQH48gju1Pd77K7/3xWe8OJus45c9t2sBV+EhKY2HS6nDpm rsjkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=istqjyGsFkKHSY0NJUgnyO84qt+ZG/fxJ8tWu8OIP uk=; b=m4xioOIpwYMGf05RQZ1JkPOVOEXb2+0e5ZAf8pY4RSZ2dBW/ZPAIFNSDK Si8iuDvKJOEtjk9mrXJzumn9huHKdK2R6PkArcRsK0Ii+ZGLyzgZxO7ao3+vSzhm Dt/73snqZ2/GlXB1O4xsZYA4tvGxK2ikDKxhhYCQ0AYWsOL/LFTl+lmVY7xkgFPK Q4HP3kTV49sFZjMOf5xT9TnBhT6e3apvlrXZ4rSpWusTrqS6XczN8fOx+mxH7fNk 6VjvVuqeaFAO4uNQsqAdOdFgpsZl8LeHP2pQlqXv8xBSzWEFEIXae3fK6s9dFHtT jD257ZzJGf+mh83myyf5Kzf2kppaA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedtgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hsthgrrhhtrdhnohdpmhhnohhtrdhnvghtnecukfhppeduvddurddvtddtrdeirddvvdei necurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (121-200-6-226.79c806.syd.nbn.aussiebb.net [121.200.6.226]) by mail.messagingengine.com (Postfix) with ESMTPA id 26A7D8005A; Tue, 8 Oct 2019 18:06:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Mark Nottingham In-Reply-To: <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> Date: Wed, 9 Oct 2019 09:06:45 +1100 Cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:07:00 -0000 Anecdata -=20 I made a proposal at the plenary mic in Montreal for a separate = last-call@ list. I'd made that proposal at least twice before to iesg@ = in the past, but it never got traction, until it was suggested I bring = it up at the mic. Once it got some support in the room, the IESG went = away and came up with a fully-baked proposal for an experiment in the = community. Under GENDISPATCH, I would have taken the proposal there (I didn't take = it to ietf@ because it was too focused on other issues, and I didn't see = it as likely to gain traction there). It would have been discussed and = presumably we would have developed a proposal in the open, guided by the = chair(s). I think that's a better outcome; certainly, as someone who wants to = suggest a change to the process, GENDISPATCH is more straightforward and = requires less "inside" knowledge. I do think there are going to be some cases where process changes are = only going to get rough consensus, and the chair(s) of GENDISPATCH need = to be able to make that consensus stick -- but that's just as it is in = every other working group. I suspect that developing the proposals and = making those calls in a public process rather than (what some perceive = to be) as proclamations from on high is a better way to promote what = resembles harmony in our community. Cheers, > On 9 Oct 2019, at 6:48 am, Ben Campbell wrote: >=20 >=20 >=20 >> On Oct 8, 2019, at 2:18 PM, Barry Leiba = wrote: >>=20 >>> At the risk of strawman-ing: If the problem is mainly that GEN = issues >>> tend to eat the IESG list, then a separate mailing list could be >>> enough. Maybe the idea is mainly to have chairs responsible for >>> discussion wrangling? If so, then a more conventional =E2=80=9CGenArea= =E2=80=9D working >>> group might do the trick. >>=20 >> I don't think it's that they "eat the IESG list" so much as that they >> "eat the IETF list=E2=80=9D. >=20 > Oops, typo on my part. I meant the IETF list. >=20 >> And not in the sense that they monopolize the >> list, but that that particular list isn't sufficiently focused to = give >> process issues proper consideration and determine what the right way >> to handle them is. =46rom my PoV, the advantage of a DISPATCH-like >> group, rather than an unfocused area group, is that the former is >> assigned the task of considering what's being discussed/proposed and >> figuring out how best to address it... rather than to just keep >> discussing it to no conclusion. >=20 > Do you think writing a charter will really change people=E2=80=99s = behavior on that matter? I imagine most people on the IETF list would = like to come to a conclusion as it is. >=20 > But as I think about this, it seems to me the main advantage of the wg = would be to have a home for discussion and some experienced chairs to = try to wrangle it. >=20 > The original promise of DISPATCH was the ability to say =E2=80=9CNo, = this is not something appropriate for the IETF to work on right now due = to (reasons).=E2=80=9D My experience is that mainly happens when there = is insufficient interest in a proposal. Even then the proponents are = often unhappy with the result. It=E2=80=99s rare for DISPATCH[ to = conclude =E2=80=9CThere are so many opinions we are unlikely to reach = consensus=E2=80=9D. Unfortunately for GENDISPATCH, I think that will be = the most common show-stopper=E2=80=94and a GENDISPATCH conclusion to = that effect will not, by itself, stop such a discussion from continuing = to eat mailing lists. >=20 > I suppose it=E2=80=99s possible that GENDISPATCH could say =E2=80=9CWe = probably can=E2=80=99t reach consensus on problem A, but maybe we can on = B an C; can people please put their energy into those now and fight = about A later?=E2=80=9D. >=20 >=20 >>> Another difference is that while DISPATCH is mainly interesting to >>> people in the ART Area, we can expect GENDISPATCH to draw from all >>> areas. We try not to let DISPATCH conflict with other ART meetings. = How >>> do you deconflict GENDISPATCH without it turning into another = plenary >>> or a standing BoF? >>=20 >> This is always an issue with Gen Area BoFs and WGs, and this will be >> no different. I think the bottom line is that there'll be a set of >> people who will want to participate regularly, and we'll try to >> accommodate that... there'll be people who want to parachute in for >> certain topics, and we'll do what we can to accommodate that, >> realizing that it's harder... and there'll be a lot of people who >> won't want to have anything to do with it until a proposal is at a >> stage where they strongly support it or object to it, and there's >> little we can do to accommodate that. It is what it is, but it's no >> different than if we just charter Gen Area WGs without a = DISPATCH-like >> start. No? >=20 >=20 > I agree that deconflicting a GenArea wg and a GenDispatch wg would be = essentially the same problem. In either case, both the =E2=80=9Cregular = set=E2=80=9D and the =E2=80=9Cparatrooper=E2=80=9D participants are = equally likely to participate in any other working group. Since = gendispatch would cover (I assume) more topics than a either a GEN bof = or =E2=80=9Cnormal" GEN wg, the deconflicting problem will be harder. = Plenary meetings would be a better comparison. >=20 > Again, I=E2=80=99m not completely opposed, just on the fence. >=20 > Ben. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Oct 8 15:20:15 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0830120813; Tue, 8 Oct 2019 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 x2Rf6g-aM5gM; Tue, 8 Oct 2019 15:19:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 773311201E5; Tue, 8 Oct 2019 15:19:59 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x98MJtBJ012661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Oct 2019 17:19:56 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570573197; bh=L9nBN9MeKBJKE+6W0A1gJIA2sY3qzqG77UpBSBPzIbg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=M0fRUJeteZS6reuo+fMVKEiar2kcOUF0YvYbiDlZExJjZ57UrqibL+nvBNghRonpQ FFWWUTAWN77DNed/I63T01mbyzUJVrFg5rlCcSiANb1fujYwRWPW7TWA9tzl3hqNJE zzq+nQL5UsjGW8j9reIPaMckozwJTthQQ64CUKOc= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> Date: Tue, 8 Oct 2019 17:19:50 -0500 Cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:20:06 -0000 > On Oct 8, 2019, at 5:06 PM, Mark Nottingham wrote: >=20 > Anecdata -=20 >=20 > I made a proposal at the plenary mic in Montreal for a separate = last-call@ list. I'd made that proposal at least twice before to iesg@ = in the past, but it never got traction, until it was suggested I bring = it up at the mic. Once it got some support in the room, the IESG went = away and came up with a fully-baked proposal for an experiment in the = community. >=20 > Under GENDISPATCH, I would have taken the proposal there (I didn't = take it to ietf@ because it was too focused on other issues, and I = didn't see it as likely to gain traction there). It would have been = discussed and presumably we would have developed a proposal in the open, = guided by the chair(s). I don=E2=80=99t disagree with any of your points. But keep in mind that, = according the proposed charter, GENDISPATCH would develop a problem = statement, context, and assess the level of interest, then pass the work = on somewhere else for the developing a solution part. For some things = that can help focus thinking. For others it can become yet another = process speed bump. For relatively self-contained proposals like the one = you suggest, I suspect it may be more of the latter. >=20 > I think that's a better outcome; certainly, as someone who wants to = suggest a change to the process, GENDISPATCH is more straightforward and = requires less "inside" knowledge. That=E2=80=99s a pretty good point=E2=80=94it=E2=80=99s possible that = GENDISPATCH could become a well-known entry point, with less guessing = about who one needs to talk to to promote an idea. DISPATCH has = occasionally had complaints from people from areas that don=E2=80=99t = use the dispatch process because it doesn=E2=80=99t match the processes = they are familiar with. But that=E2=80=99s probably easier for something = with more cross-area appeal. >=20 > I do think there are going to be some cases where process changes are = only going to get rough consensus, and the chair(s) of GENDISPATCH need = to be able to make that consensus stick -- but that's just as it is in = every other working group. I suspect that developing the proposals and = making those calls in a public process rather than (what some perceive = to be) as proclamations from on high is a better way to promote what = resembles harmony in our community. No disagreement there. Thanks! Ben. From nobody Wed Oct 9 22:21:48 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA275120043; Wed, 9 Oct 2019 22:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 cDXQvdkZIEEI; Wed, 9 Oct 2019 22:21:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514FA120044; Wed, 9 Oct 2019 22:21:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iIQtH-000HxA-TV; Thu, 10 Oct 2019 01:21:31 -0400 Date: Thu, 10 Oct 2019 01:21:23 -0400 From: John C Klensin To: Barry Leiba , Ben Campbell cc: gendispatch@ietf.org, IETF discussion list , The IESG Message-ID: <246B8C1AAC97E005097CAF12@PSB> In-Reply-To: References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 05:21:37 -0000 --On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba wrote: >... >> Another difference is that while DISPATCH is mainly >> interesting to people in the ART Area, we can expect >> GENDISPATCH to draw from all areas. We try not to let >> DISPATCH conflict with other ART meetings. How do you >> deconflict GENDISPATCH without it turning into another plenary >> or a standing BoF? > > This is always an issue with Gen Area BoFs and WGs, and this > will be no different. I think the bottom line is that > there'll be a set of people who will want to participate > regularly, and we'll try to accommodate that... there'll be > people who want to parachute in for certain topics, and we'll > do what we can to accommodate that, realizing that it's > harder... and there'll be a lot of people who won't want to > have anything to do with it until a proposal is at a stage > where they strongly support it or object to it, and there's > little we can do to accommodate that. It is what it is, but > it's no different than if we just charter Gen Area WGs without > a DISPATCH-like start. No? Barry, I see one risk with this that I think should be considered and watched for even if the IESG decides to move forward. The IETF has a rather long and difficult history, with only a few exceptions since the POISED and POISSON WGs, of there being two types of process change proposals. One type is enthusiastically welcomed by the IESG. A large fraction of proposals of that type originated within the IESG (or occasionally the IAB) and were pushed at the community rather than being in any sense bottom-up. That is not necessarily bad -- your work (and Thomas's and Harald's) on IANA Considerations is, IMO, one of the more positive examples. Others are not. They, and especially ones that members of the IESG see as a threat to their authority or the way they do things and sometimes as adding work, have tended to vanish. Often they vanish without a trace, with no opportunity for the community to take positions on Last Call, sometimes inconsistent with WG consensus, and usually with very little accountability for individual ADs or the IESG in general. I (and some others) routinely cite NEWTRK as an example but there are others. In many of them, the IESG has insisted that a working group is needed and then refused to create such a working group (or has created one with a charter so narrow or broad as to make progress impossible) as a means of killing the effort. In others, ADs have managed to erect sufficient obstacles and induce enough delays that people simply lose interest. Sometimes that is A Good Thing; often it is a control mechanism that keep particular people or points of view in power and prevent the IETF from evolving and making progress. So, the question about this proposed WG for me is whether it will make those tendencies better and thereby prevent good ideas from getting lost or suppressed. If so, I think it is a great idea. But I also see the risk of its being used to bury work that it out of favor with "the leadership" and doing so in a way that preserves the status quo except when the IESG wishes things to be different) and enables even less transparency and accountability than we have seen in the past. I'd like to see ideas and controls about how to prevent the latter or how to detect it and push back if it starts to occur, and I don't see those in the current draft specification. best, john From nobody Thu Oct 10 08:53:13 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0372112001A; Thu, 10 Oct 2019 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 1827ccoaX6Al; Thu, 10 Oct 2019 08:52:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 711E212011E; Thu, 10 Oct 2019 08:52:57 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9AFqnDb032233 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Oct 2019 10:52:51 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570722772; bh=Zd/WNqGfWRWUHQv86vksRF2mPJ6/kk4MwirTHAVmbOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZcyTqE96no+zMbrPbkUQKH9uT9RITZNeQ5CGCPLv6vnr+uzsBMuYcLMtP9vZuN1aS BU8B+rWqRiJmJwoLiPIWtUEv4F+WheBkR1uRYadUxbu5ngRQv3YaaR46FrSH5CpWst FAbnF2dAGECnlMA+13FOcqcd/+4M4pRhzObzQrLQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: <246B8C1AAC97E005097CAF12@PSB> Date: Thu, 10 Oct 2019 10:52:43 -0500 Cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <246B8C1AAC97E005097CAF12@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 15:53:00 -0000 > On Oct 10, 2019, at 12:21 AM, John C Klensin = wrote: >=20 >=20 >=20 > --On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba > wrote: >=20 >> ... >>> Another difference is that while DISPATCH is mainly >>> interesting to people in the ART Area, we can expect >>> GENDISPATCH to draw from all areas. We try not to let >>> DISPATCH conflict with other ART meetings. How do you >>> deconflict GENDISPATCH without it turning into another plenary >>> or a standing BoF? >>=20 >> This is always an issue with Gen Area BoFs and WGs, and this >> will be no different. I think the bottom line is that >> there'll be a set of people who will want to participate >> regularly, and we'll try to accommodate that... there'll be >> people who want to parachute in for certain topics, and we'll >> do what we can to accommodate that, realizing that it's >> harder... and there'll be a lot of people who won't want to >> have anything to do with it until a proposal is at a stage >> where they strongly support it or object to it, and there's >> little we can do to accommodate that. It is what it is, but >> it's no different than if we just charter Gen Area WGs without >> a DISPATCH-like start. No? >=20 > Barry, >=20 > I see one risk with this that I think should be considered and > watched for even if the IESG decides to move forward. >=20 > The IETF has a rather long and difficult history, with only a > few exceptions since the POISED and POISSON WGs, of there being > two types of process change proposals. One type is > enthusiastically welcomed by the IESG. A large fraction of > proposals of that type originated within the IESG (or > occasionally the IAB) and were pushed at the community rather > than being in any sense bottom-up. That is not necessarily bad > -- your work (and Thomas's and Harald's) on IANA Considerations > is, IMO, one of the more positive examples. Others are not. > They, and especially ones that members of the IESG see as a > threat to their authority or the way they do things and > sometimes as adding work, have tended to vanish. Often they > vanish without a trace, with no opportunity for the community to > take positions on Last Call, sometimes inconsistent with WG > consensus, and usually with very little accountability for > individual ADs or the IESG in general. I (and some others) > routinely cite NEWTRK as an example but there are others. In > many of them, the IESG has insisted that a working group is > needed and then refused to create such a working group (or has > created one with a charter so narrow or broad as to make > progress impossible) as a means of killing the effort. In > others, ADs have managed to erect sufficient obstacles and > induce enough delays that people simply lose interest. > Sometimes that is A Good Thing; often it is a control mechanism > that keep particular people or points of view in power and > prevent the IETF from evolving and making progress. >=20 > So, the question about this proposed WG for me is whether it > will make those tendencies better and thereby prevent good ideas > from getting lost or suppressed. If so, I think it is a great > idea. But I also see the risk of its being used to bury work > that it out of favor with "the leadership" and doing so in a way > that preserves the status quo except when the IESG wishes things > to be different) and enables even less transparency and > accountability than we have seen in the past. I'd like to see > ideas and controls about how to prevent the latter or how to > detect it and push back if it starts to occur, and I don't see > those in the current draft specification. Hi John, This brings up another question in my mind. The ART ADs typically treat = DISPATCH decisions as non-binding recommendations. Likewise, the ADs may = skip DISPATCH and take proposals straight to BoF or even WG formation if = they think it appropriate. Would GENDISPATCH decisions be treated the same, or would they be = binding on the IESG? I had assumed the former, in the sense that AD = discretion applies to pretty much any working group. Whichever case is = the answer, I think the charter needs to be explicit about it. Thanks! Ben. From nobody Thu Oct 10 09:05:28 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3985112001A; Thu, 10 Oct 2019 09:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 W3Ivm97tLrCG; Thu, 10 Oct 2019 09:05:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D84D31200C3; Thu, 10 Oct 2019 09:05:24 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9AG5Lc0034381 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Oct 2019 11:05:22 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570723523; bh=wNtmjcwkrvJBDz5avsMqTak5fNK6VqlpG4Jj91szrfw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=W7ucCSF/DbaqQl8y1pJDkIU7tokcS+ShlBcdsYf3WelA7werAImjC58NVhoQ3n5LM FWq6gyb406uGiwHpqs2QgJVLDwNV/YWHrwiuy521PCVlpIY4hUvjs9jupbrufBKhKS HmVPOIZl3jLkqxu/86JQZmC2vuLPe7CgwGFz7W9Y= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> Date: Thu, 10 Oct 2019 11:05:14 -0500 Cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 16:05:26 -0000 Here=E2=80=99s an attempt to distill my concern a little better: The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of as a = triage process. Triage makes sense when you don=E2=80=99t have the time = and resources to address every problem and have to pick and choose where = you can have the most impact. If you do have time and resources to = address everything, then triage is just a process bump.=20 Do we believe that GEN area proposals will routinely exceed our capacity = to discuss them? If so, do we think that will continue to be true for = the foreseeable future? (I assume this is intended to be a long-lived = wg). Thanks! Ben. > On Oct 8, 2019, at 5:19 PM, Ben Campbell wrote: >=20 >=20 >> On Oct 8, 2019, at 5:06 PM, Mark Nottingham wrote: >>=20 >> Anecdata -=20 >>=20 >> I made a proposal at the plenary mic in Montreal for a separate = last-call@ list. I'd made that proposal at least twice before to iesg@ = in the past, but it never got traction, until it was suggested I bring = it up at the mic. Once it got some support in the room, the IESG went = away and came up with a fully-baked proposal for an experiment in the = community. >>=20 >> Under GENDISPATCH, I would have taken the proposal there (I didn't = take it to ietf@ because it was too focused on other issues, and I = didn't see it as likely to gain traction there). It would have been = discussed and presumably we would have developed a proposal in the open, = guided by the chair(s). >=20 > I don=E2=80=99t disagree with any of your points. But keep in mind = that, according the proposed charter, GENDISPATCH would develop a = problem statement, context, and assess the level of interest, then pass = the work on somewhere else for the developing a solution part. For some = things that can help focus thinking. For others it can become yet = another process speed bump. For relatively self-contained proposals like = the one you suggest, I suspect it may be more of the latter. >=20 >>=20 >> I think that's a better outcome; certainly, as someone who wants to = suggest a change to the process, GENDISPATCH is more straightforward and = requires less "inside" knowledge. >=20 > That=E2=80=99s a pretty good point=E2=80=94it=E2=80=99s possible that = GENDISPATCH could become a well-known entry point, with less guessing = about who one needs to talk to to promote an idea. DISPATCH has = occasionally had complaints from people from areas that don=E2=80=99t = use the dispatch process because it doesn=E2=80=99t match the processes = they are familiar with. But that=E2=80=99s probably easier for something = with more cross-area appeal. >=20 >>=20 >> I do think there are going to be some cases where process changes are = only going to get rough consensus, and the chair(s) of GENDISPATCH need = to be able to make that consensus stick -- but that's just as it is in = every other working group. I suspect that developing the proposals and = making those calls in a public process rather than (what some perceive = to be) as proclamations from on high is a better way to promote what = resembles harmony in our community. >=20 > No disagreement there. >=20 > Thanks! >=20 > Ben. >=20 From nobody Thu Oct 10 12:47:21 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BBC12084A; Thu, 10 Oct 2019 12:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yk7UDKe8snKn; Thu, 10 Oct 2019 12:47:12 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 5A66E12082A; Thu, 10 Oct 2019 12:47:12 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id q24so3272559plr.13; Thu, 10 Oct 2019 12:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e3FWjpULJMKbxCScmF8pgQryAwAbPpnA7DPkt0cHuRE=; b=GDFxWuJYmFy4PqqN0p4c5ESd0bcPlpZL+PrDiMvAWouLXU3bHGodC7pyfrKGEFt9wO gUZzzweS86R9j1Y/TVs2CYggWfKCsPUv4I2Mrq/a4j1gIU6siS+YnRP9TzP/zZ6ECn1R 4SAOZyPgFfvwDW4RiHpB3ez6BVtc6tdFh2NWOR25maZMZVWvaN5mp03n29x0dRis8V5r aQMrNVAIOpTDOM/SfuvZ7waUbzoxWBlUayDDa4fT7vu+gWrUYiFP+pCL8h3gl7zNzhW9 lFjyFGDrWyKCCyF9oYQ3RJGYmLwd+0Ig/MhNSMjLzZ7GUhV6ukalB9iJRBadRLUlrtJ+ 2aUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e3FWjpULJMKbxCScmF8pgQryAwAbPpnA7DPkt0cHuRE=; b=SHFj1FAtO3UQXl5u2bF9wkCEWZ8FMB3styAtVK9GvH+pTwweO+Ep9FcodkSBI17ymz l2E1RHfSumLYzVPEkXFqXBQl04jTs4k4j3GylEDzOFKTS/W4Bev02rLDpKLd+w7mFn1y IpzY4DxFfsMwqh/8QQdMcnKr5D1EUFOEhf3X9DRY5rGwXLVDcPz7BFLocMmzro+JmID1 k2+ie/TvmH+Oq5LKHTQ+fHeZkhsDd6K8BQnO6RPYRckd0QpV68tMxLdt80ce1v7O83bV rmAhqJQwK5w2GLYeVGkfMzGGGrvtNswL4qmy9UbykIW9Y+C7vRv6EO0NeZDyMO38Xt5X Dnzg== X-Gm-Message-State: APjAAAW9pPNsnbapvPg7kul1NL1M3u72GJtbshNJk3K/g6QOHbRohIul H3tNi/WqmRxTNVYSVBcFMzbSVLxF X-Google-Smtp-Source: APXvYqwrPFzBq8npF2ZiuQD87NnuBFwGlKlWRC8SaX+UW7ajenjo7CFWvwEzi7UZ0RWph92XJceC5w== X-Received: by 2002:a17:902:6946:: with SMTP id k6mr11412895plt.60.1570736831294; Thu, 10 Oct 2019 12:47:11 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id p11sm6774100pgs.51.2019.10.10.12.47.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Oct 2019 12:47:10 -0700 (PDT) To: Ben Campbell , Mark Nottingham Cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> From: Brian E Carpenter Message-ID: Date: Fri, 11 Oct 2019 08:47:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 19:47:20 -0000 On 11-Oct-19 05:05, Ben Campbell wrote: > Here=E2=80=99s an attempt to distill my concern a little better: >=20 > The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of as = a triage process. Triage makes sense when you don=E2=80=99t have the time= and resources to address every problem and have to pick and choose where= you can have the most impact. If you do have time and resources to addre= ss everything, then triage is just a process bump.=20 >=20 > Do we believe that GEN area proposals will routinely exceed our capacit= y to discuss them? If so, do we think that will continue to be true for t= he foreseeable future? (I assume this is intended to be a long-lived wg).= I think that we have never really had a problem handling minor process fi= xes. That's why we have so many process-related RFCs, in fact. For those,= GENDISPATCH will clearly help us do the triage a bit more systematically= , and that is a Good Thing.=20 Where we've had a problem, for the last 20 years, is in achieving major p= rocess changes. Actually we haven't really had any, except RFC 6410. IMHO= all the other updates to RFC 2026 were clarifications and tuning. (Of co= urse opinions on this may vary.) And even that change was really a rather= late recognition of reality. For major change to occur, we need a strong community will and a flexible= IESG. GENDISPATCH won't automatically achieve that, because there's a te= ndency to put proposals for major change on the "too hard" heap. But at l= east GENDISPATCH offers a mechanism for discussing proposals for major ch= ange, and that too is a Good Thing. Regards Brian >=20 > Thanks! >=20 > Ben. >=20 >=20 >> On Oct 8, 2019, at 5:19 PM, Ben Campbell wrote: >> >> >>> On Oct 8, 2019, at 5:06 PM, Mark Nottingham wrote: >>> >>> Anecdata -=20 >>> >>> I made a proposal at the plenary mic in Montreal for a separate last-= call@ list. I'd made that proposal at least twice before to iesg@ in the = past, but it never got traction, until it was suggested I bring it up at = the mic. Once it got some support in the room, the IESG went away and cam= e up with a fully-baked proposal for an experiment in the community. >>> >>> Under GENDISPATCH, I would have taken the proposal there (I didn't ta= ke it to ietf@ because it was too focused on other issues, and I didn't s= ee it as likely to gain traction there). It would have been discussed and= presumably we would have developed a proposal in the open, guided by the= chair(s). >> >> I don=E2=80=99t disagree with any of your points. But keep in mind tha= t, according the proposed charter, GENDISPATCH would develop a problem st= atement, context, and assess the level of interest, then pass the work on= somewhere else for the developing a solution part. For some things that = can help focus thinking. For others it can become yet another process spe= ed bump. For relatively self-contained proposals like the one you suggest= , I suspect it may be more of the latter. >> >>> >>> I think that's a better outcome; certainly, as someone who wants to s= uggest a change to the process, GENDISPATCH is more straightforward and r= equires less "inside" knowledge. >> >> That=E2=80=99s a pretty good point=E2=80=94it=E2=80=99s possible that = GENDISPATCH could become a well-known entry point, with less guessing abo= ut who one needs to talk to to promote an idea. DISPATCH has occasionally= had complaints from people from areas that don=E2=80=99t use the dispatc= h process because it doesn=E2=80=99t match the processes they are familia= r with. But that=E2=80=99s probably easier for something with more cross-= area appeal. >> >>> >>> I do think there are going to be some cases where process changes are= only going to get rough consensus, and the chair(s) of GENDISPATCH need = to be able to make that consensus stick -- but that's just as it is in ev= ery other working group. I suspect that developing the proposals and maki= ng those calls in a public process rather than (what some perceive to be)= as proclamations from on high is a better way to promote what resembles = harmony in our community. >> >> No disagreement there. >> >> Thanks! >> >> Ben. >> >=20 From nobody Fri Oct 11 02:07:27 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8B120043; Fri, 11 Oct 2019 02:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 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_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=kdUmIS1n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SGLG+7J2 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 867aMwnGKeP2; Fri, 11 Oct 2019 02:07:22 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70E8120020; Fri, 11 Oct 2019 02:07:22 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id A33E258C; Fri, 11 Oct 2019 05:07:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 11 Oct 2019 05:07:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=qqw5F5dSWGepc6d7+yZVfkV XVnAQqnHZnlUPmpZW0uY=; b=kdUmIS1nnk6gNyhgpzqAdhYrZAY5hNCTC+MJ0XI UyUecjwfME6WhWvlAmVpfRBiFlRPp2wObe1TCNyUZfnZ5z+LjWnU6X2gxmzO5E+J unSIArXjA7OzP8jiQcBLmu0OPQSOXJvoutxu5MiZ/T6mwu4wQ7hjQoPHTBqm+rc5 +LCweYmjkRM8U1MK+SUp9EYPj3k8ilyy1xfmO48hTUOpB0oRVIKXiIElyLiY5lD0 a6sFfwKqfKQyQrijC69G73l2+brnN509tOYUm9vqpwaS4vAQVKgYPmDEH3xKVYB6 uqgI6g9coSPGBDksHjZmbvNM4z3ChW415se35DQNS5lwpkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qqw5F5 dSWGepc6d7+yZVfkVXVnAQqnHZnlUPmpZW0uY=; b=SGLG+7J21iTc8n8YHK/uCu Ko23IxKbBkZpMb9C/nP4w/wRZeFToysrfJAHm35aUogVjes6iuVI2bJNSgNmIGqb EBTii5StO1o1j+KrE5rQzSGSlS8Wg3zyGLXLF4QeVbfMWP6Zkp5Icwr6/G/fTqBQ CEa7po7NxjR9DzGI5tW0pTAu1/Tu1y2PTyOXv5gPBSgkL9bVuGpCOJ3uARipv/0G EqH1N/LRBP77VsFagp+ViA1l5N30KhLjhxqw8DZGFtMfW+EYMkB1ZqJHsClysJeI MK7dLzBiby/KFAXYCvtqv4ZzpjCO1EmdmGTP9tXP6FWMB88yRh96uzTOJpplikzQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinh epshhtrghrthdrnhhopdhivghtfhdrohhrghenucfkphepkeelrddvgeekrddugedtrddu heenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.22.150.10] (unknown [89.248.140.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8568F8005C; Fri, 11 Oct 2019 05:07:19 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E674D5E6-ACA0-4C3D-97C6-0B12850287A8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 11 Oct 2019 11:07:17 +0200 In-Reply-To: <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> Cc: John C Klensin , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG To: Ben Campbell References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <246B8C1AAC97E005097CAF12@PSB> <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:07:25 -0000 --Apple-Mail=_E674D5E6-ACA0-4C3D-97C6-0B12850287A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, > On Oct 10, 2019, at 5:52 PM, Ben Campbell wrote: >=20 >=20 >=20 >> On Oct 10, 2019, at 12:21 AM, John C Klensin = wrote: >>=20 >>=20 >>=20 >> --On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba >> wrote: >>=20 >>> ... >>>> Another difference is that while DISPATCH is mainly >>>> interesting to people in the ART Area, we can expect >>>> GENDISPATCH to draw from all areas. We try not to let >>>> DISPATCH conflict with other ART meetings. How do you >>>> deconflict GENDISPATCH without it turning into another plenary >>>> or a standing BoF? >>>=20 >>> This is always an issue with Gen Area BoFs and WGs, and this >>> will be no different. I think the bottom line is that >>> there'll be a set of people who will want to participate >>> regularly, and we'll try to accommodate that... there'll be >>> people who want to parachute in for certain topics, and we'll >>> do what we can to accommodate that, realizing that it's >>> harder... and there'll be a lot of people who won't want to >>> have anything to do with it until a proposal is at a stage >>> where they strongly support it or object to it, and there's >>> little we can do to accommodate that. It is what it is, but >>> it's no different than if we just charter Gen Area WGs without >>> a DISPATCH-like start. No? >>=20 >> Barry, >>=20 >> I see one risk with this that I think should be considered and >> watched for even if the IESG decides to move forward. >>=20 >> The IETF has a rather long and difficult history, with only a >> few exceptions since the POISED and POISSON WGs, of there being >> two types of process change proposals. One type is >> enthusiastically welcomed by the IESG. A large fraction of >> proposals of that type originated within the IESG (or >> occasionally the IAB) and were pushed at the community rather >> than being in any sense bottom-up. That is not necessarily bad >> -- your work (and Thomas's and Harald's) on IANA Considerations >> is, IMO, one of the more positive examples. Others are not. >> They, and especially ones that members of the IESG see as a >> threat to their authority or the way they do things and >> sometimes as adding work, have tended to vanish. Often they >> vanish without a trace, with no opportunity for the community to >> take positions on Last Call, sometimes inconsistent with WG >> consensus, and usually with very little accountability for >> individual ADs or the IESG in general. I (and some others) >> routinely cite NEWTRK as an example but there are others. In >> many of them, the IESG has insisted that a working group is >> needed and then refused to create such a working group (or has >> created one with a charter so narrow or broad as to make >> progress impossible) as a means of killing the effort. In >> others, ADs have managed to erect sufficient obstacles and >> induce enough delays that people simply lose interest. >> Sometimes that is A Good Thing; often it is a control mechanism >> that keep particular people or points of view in power and >> prevent the IETF from evolving and making progress. >>=20 >> So, the question about this proposed WG for me is whether it >> will make those tendencies better and thereby prevent good ideas >> from getting lost or suppressed. If so, I think it is a great >> idea. But I also see the risk of its being used to bury work >> that it out of favor with "the leadership" and doing so in a way >> that preserves the status quo except when the IESG wishes things >> to be different) and enables even less transparency and >> accountability than we have seen in the past. I'd like to see >> ideas and controls about how to prevent the latter or how to >> detect it and push back if it starts to occur, and I don't see >> those in the current draft specification. >=20 > Hi John, >=20 > This brings up another question in my mind. The ART ADs typically = treat DISPATCH decisions as non-binding recommendations. Likewise, the = ADs may skip DISPATCH and take proposals straight to BoF or even WG = formation if they think it appropriate. >=20 > Would GENDISPATCH decisions be treated the same, or would they be = binding on the IESG? I had assumed the former, in the sense that AD = discretion applies to pretty much any working group. Whichever case is = the answer, I think the charter needs to be explicit about it. I changed the sentence about RFC 3710 so it now includes the word = =E2=80=9Cdiscretion.=E2=80=9D = https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ Best, Alissa >=20 > Thanks! >=20 > Ben. >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch = --Apple-Mail=_E674D5E6-ACA0-4C3D-97C6-0B12850287A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

On Oct 10, 2019, at 5:52 PM, Ben Campbell = <ben@nostrum.com> = wrote:



On = Oct 10, 2019, at 12:21 AM, John C Klensin <john-ietf@jck.com> = wrote:



--On = Tuesday, October 8, 2019 21:18 +0200 Barry Leiba
<barryleiba@computer.org> wrote:

...
Another difference is = that while DISPATCH is mainly
interesting to people in the = ART Area, we can expect
GENDISPATCH to draw from all = areas. We try not to let
DISPATCH conflict with other ART = meetings. How do you
deconflict GENDISPATCH without it = turning into another plenary
or a standing BoF?

This is always an issue with Gen = Area BoFs and WGs, and this
will be no different.  I = think the bottom line is that
there'll be a set of people = who will want to participate
regularly, and we'll try to = accommodate that... there'll be
people who want to = parachute in for certain topics, and we'll
do what we can = to accommodate that, realizing that it's
harder... and = there'll be a lot of people who won't want to
have = anything to do with it until a proposal is at a stage
where = they strongly support it or object to it, and there's
little= we can do to accommodate that.  It is what it is, but
it's no different than if we just charter Gen Area WGs = without
a DISPATCH-like start.  No?

Barry,

I see one risk with this that I think should be considered = and
watched for even if the IESG decides to move = forward.

The IETF has a rather long and = difficult history, with only a
few exceptions since the = POISED and POISSON WGs, of there being
two types of = process change proposals.  One type is
enthusiastically= welcomed by the IESG.  A large fraction  of
proposals of that type originated within the IESG (or
occasionally the IAB) and were pushed at the community = rather
than being in any sense bottom-up.  That is = not necessarily bad
-- your work (and Thomas's and = Harald's) on IANA Considerations
is, IMO, one of the more = positive examples.   Others are not.
They, and = especially ones that members of the IESG see as a
threat = to their authority or the way they do things and
sometimes = as adding work, have tended to vanish.  Often they
vanish without a trace, with no opportunity for the community = to
take positions on Last Call, sometimes inconsistent = with WG
consensus, and usually with very little = accountability for
individual ADs or the IESG in general. =  I (and some others)
routinely cite NEWTRK as an = example but there are others.  In
many of them, the = IESG has insisted that a working group is
needed and then = refused to create such a working group (or has
created one = with a charter so narrow or broad as to make
progress = impossible) as a means of killing the effort.  In
others, ADs have managed to erect sufficient obstacles and
induce enough delays that people simply lose interest.
Sometimes that is A Good Thing; often it is a control = mechanism
that keep particular people or points of view in = power and
prevent the IETF from evolving and making = progress.

So, the question about this = proposed WG for me is whether it
will make those = tendencies better and thereby prevent good ideas
from = getting lost or suppressed.   If so, I think it is a great
idea.   But I also see the risk of its being used = to bury work
that it out of favor with "the leadership" = and doing so in a way
that preserves the status quo except = when the IESG wishes things
to be different) and enables = even less transparency and
accountability than we have = seen in the past.  I'd like to see
ideas and controls = about how to prevent the latter or how to
detect it and = push back if it starts to occur, and I don't see
those in = the current draft specification.

Hi John,

This brings up another question = in my mind. The ART ADs typically treat DISPATCH decisions as = non-binding recommendations. Likewise, the ADs may skip DISPATCH and = take proposals straight to BoF or even WG formation if they think it = appropriate.

Would = GENDISPATCH decisions be treated the same, or would they be binding on = the IESG? I had assumed the former, in the sense that AD discretion = applies to pretty much any working group. Whichever case is the answer, = I think the charter needs to be explicit about it.

I changed = the sentence about RFC 3710 so it now includes the word = =E2=80=9Cdiscretion.=E2=80=9D https://datatracker.ietf.org/doc/charter-ietf-gendispatch/<= /div>

Best,
Alissa


Thanks!

Ben.

-- 
Gendispatch mailing = list
Gendispatch@ietf.org
https://www.ietf.org/mailman/listinfo/gendispatch

= --Apple-Mail=_E674D5E6-ACA0-4C3D-97C6-0B12850287A8-- From nobody Fri Oct 11 02:10:34 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFC1120043; Fri, 11 Oct 2019 02:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Y0WKI4Ef; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FcJvpciR 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 tuo642vNeNcf; Fri, 11 Oct 2019 02:10:31 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7BE120020; Fri, 11 Oct 2019 02:10:31 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 6BB085AC; Fri, 11 Oct 2019 05:10:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 11 Oct 2019 05:10:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=0 1miGXdw8fkO0BEZBW2bWqJSg41CPOdtsYjp3lkbiOM=; b=Y0WKI4Efj6sQQ/NwG 5DATRhsyErXEvfkpZj1ryL9rvqe0cmu9WD17VEjCxHlpW1cHBnkHd/3y86PdIY6E gO82hJR3U5dkHBcQUuKA5GrrViR7zkLTbpr7fVO6+ShjXZKPVU0qDLuGQinar7d3 OZBaFDSrhKQsMV+t8opmg/LQsP5edv5VHllzgN6HeuB9GYGu7ylM1YmlIBD5RqUG vvC5sZPTN0nRMpOZA80PyNNx0jwZDykrBqfXYAtzMR20SVvE2xInR5HTFqjCVXRa faH1rdhmfbIr+jmhkqrh05FKxtuN+UUQahpEWhlsmbl/hr6J1hMGPJWbzHmlz9bR iI9lw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=01miGXdw8fkO0BEZBW2bWqJSg41CPOdtsYjp3lkbi OM=; b=FcJvpciRiXwRfF28Vy5AtbSzTqiBMXamfrmlwFddS+B8h/j3mhYPonKT/ meJd/RhvoggU3+itMyxAUGM8WzbAieHRPTjtMigE4ca/nrOXiXb9o1O4cUXg1QOy OXGbpNs1S5jZ2PRFoGOueevpOPcqMukQmAvNvcaHtpbL38q75IBAR1n5tNZzZJwN boyehZgEn4dUwxL4dAJ+tdQziTJm78R5F6stVsFaqQGE/k4PYbe13an0a153nXZ1 HMmj+37xmnTOjA5kZVt/4j+mAKesh4UwHhF9CUcOZOAE5kxB4YbTVN3/LpheDIQh vEu2V8DYYMHkAqPqFIn2qpePBPgTQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepkeelrddvgeekrddugedtrdduheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from [10.22.150.10] (unknown [89.248.140.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 92D258005B; Fri, 11 Oct 2019 05:10:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> Date: Fri, 11 Oct 2019 11:10:26 +0200 Cc: Mark Nottingham , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <18383AE8-9AF2-4C93-8598-EF33F7E49A4B@cooperw.in> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:10:33 -0000 Hi Ben, > On Oct 10, 2019, at 6:05 PM, Ben Campbell wrote: >=20 > Here=E2=80=99s an attempt to distill my concern a little better: >=20 > The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of as = a triage process. Triage makes sense when you don=E2=80=99t have the = time and resources to address every problem and have to pick and choose = where you can have the most impact. If you do have time and resources to = address everything, then triage is just a process bump.=20 >=20 > Do we believe that GEN area proposals will routinely exceed our = capacity to discuss them? If so, do we think that will continue to be = true for the foreseeable future? (I assume this is intended to be a = long-lived wg). I guess I see the question differently. If there are people in the = community who are willing to manage discussions about process proposals = while they=E2=80=99re in formation (i.e., people willing to chair this = WG), that seems like a better arrangement than the current one both from = the perspective of being more community-led and from the perspective of = the other time commitments that the IESG has. If the WG isn=E2=80=99t = busy or meeting all the time, that=E2=80=99s fine =E2=80=94 it will = still be nice to have it there for times when process proposals do come = up and inspire discussion. Best, Alissa=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 >> On Oct 8, 2019, at 5:19 PM, Ben Campbell wrote: >>=20 >>=20 >>> On Oct 8, 2019, at 5:06 PM, Mark Nottingham wrote: >>>=20 >>> Anecdata -=20 >>>=20 >>> I made a proposal at the plenary mic in Montreal for a separate = last-call@ list. I'd made that proposal at least twice before to iesg@ = in the past, but it never got traction, until it was suggested I bring = it up at the mic. Once it got some support in the room, the IESG went = away and came up with a fully-baked proposal for an experiment in the = community. >>>=20 >>> Under GENDISPATCH, I would have taken the proposal there (I didn't = take it to ietf@ because it was too focused on other issues, and I = didn't see it as likely to gain traction there). It would have been = discussed and presumably we would have developed a proposal in the open, = guided by the chair(s). >>=20 >> I don=E2=80=99t disagree with any of your points. But keep in mind = that, according the proposed charter, GENDISPATCH would develop a = problem statement, context, and assess the level of interest, then pass = the work on somewhere else for the developing a solution part. For some = things that can help focus thinking. For others it can become yet = another process speed bump. For relatively self-contained proposals like = the one you suggest, I suspect it may be more of the latter. >>=20 >>>=20 >>> I think that's a better outcome; certainly, as someone who wants to = suggest a change to the process, GENDISPATCH is more straightforward and = requires less "inside" knowledge. >>=20 >> That=E2=80=99s a pretty good point=E2=80=94it=E2=80=99s possible that = GENDISPATCH could become a well-known entry point, with less guessing = about who one needs to talk to to promote an idea. DISPATCH has = occasionally had complaints from people from areas that don=E2=80=99t = use the dispatch process because it doesn=E2=80=99t match the processes = they are familiar with. But that=E2=80=99s probably easier for something = with more cross-area appeal. >>=20 >>>=20 >>> I do think there are going to be some cases where process changes = are only going to get rough consensus, and the chair(s) of GENDISPATCH = need to be able to make that consensus stick -- but that's just as it is = in every other working group. I suspect that developing the proposals = and making those calls in a public process rather than (what some = perceive to be) as proclamations from on high is a better way to promote = what resembles harmony in our community. >>=20 >> No disagreement there. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Fri Oct 11 06:09:17 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8286B120090; Fri, 11 Oct 2019 06:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HNeZNFEpO4iX; Fri, 11 Oct 2019 06:09:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9DF120088; Fri, 11 Oct 2019 06:09:05 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iIufG-000PZS-P5; Fri, 11 Oct 2019 09:09:02 -0400 Date: Fri, 11 Oct 2019 09:08:53 -0400 From: John C Klensin To: Ben Campbell cc: Barry Leiba , gendispatch@ietf.org, IETF discussion list , The IESG Message-ID: <2314FC25F986AD589B74D8FA@PSB> In-Reply-To: <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <246B8C1AAC97E005097CAF12@PSB> <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:09:08 -0000 --On Thursday, October 10, 2019 10:52 -0500 Ben Campbell wrote: >> So, the question about this proposed WG for me is whether it >> will make those tendencies better and thereby prevent good >> ideas from getting lost or suppressed. If so, I think it is >> a great idea. But I also see the risk of its being used to >> bury work that it out of favor with "the leadership" and >> doing so in a way that preserves the status quo except when >> the IESG wishes things to be different) and enables even less >> transparency and accountability than we have seen in the >> past. I'd like to see ideas and controls about how to >> prevent the latter or how to detect it and push back if it >> starts to occur, and I don't see those in the current draft >> specification. > > Hi John, > > This brings up another question in my mind. The ART ADs > typically treat DISPATCH decisions as non-binding > recommendations. Likewise, the ADs may skip DISPATCH and take > proposals straight to BoF or even WG formation if they think > it appropriate. > > Would GENDISPATCH decisions be treated the same, or would they > be binding on the IESG? I had assumed the former, in the sense > that AD discretion applies to pretty much any working group. > Whichever case is the answer, I think the charter needs to be > explicit about it. Ben, I had assumed the former as well. I think that taking that discretion away from ADs would put us into a place where we really do not want to go. In particular, one can imagine situations in which ADs would be forced to manage WGs they would like to have fail and there are just too many ways in which failures can be encouraged or the WG's work subverted. At the same time, we've occasionally seen that discretion used in a way that is arguably abusive. It is my impression that has occurred more often with process proposals than anything else and that is most of what prompted the note to which you responded. It had not occurred to me until now, but I think that concern segues into your comments to Mark about a triage process. If we really mean triage, we mean something that is relatively quick and decisive. One of my concerns has been that the existence of such a WG could be used to drag things out, as in "we can't consider this until GENDISPATCH meets", then "interesting discussion, let's postpone to the next meeting", then "this really needs a WG for itself", then some delay in getting the WG organized because no one on the IESG is enthused, then... One can easily imagine things being dragged out for close to a year, or longer, until people lose interest or accept the status quo as fated. Perhaps a few guidelines and timelines would help alleviate that concern. For example, that the WG gets only one shot (no postponements to the next IETF) and that, if GENDISPATCH concludes that a WG is needed, it starts a clock ticking by which the WG has to be either organized, formed, and in operation or the IESG is required to explain the delay to the community. Probably mechanisms like that would be a net improvement over the current situation although my concern that the IESG and the community should watch this very carefully remains. That concern is especially strong if the leadership of the WG is different from the relevant AD(s): on the one hand, that can improve efficiency because ADs are overworked. On the other, because that chair or those co-chairs are not nomcom-appointed or subject to recall, there is less direct accountability to the community and more ability for the IESG (or a particular AD) to throw the co-chairs under an approaching bus and therefore avoid accountability (or course, we've never seen things like that happen in other areas of the IETF/IAB's work). best, john From nobody Fri Oct 11 12:01:07 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0891200EB; Fri, 11 Oct 2019 12:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 jU3Pd7fu4C3f; Fri, 11 Oct 2019 12:00:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5C447120143; Fri, 11 Oct 2019 12:00:55 -0700 (PDT) Received: from [10.48.10.6] (ip-108-232-239-173.texas.us.northamericancoax.com [173.239.232.108]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9BJ0gao063774 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Oct 2019 14:00:44 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570820445; bh=mvSLGvSzawzXxjaS+xQeE9AlEfbj/zsqQh9u2si830w=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=hJJb7kghAjA4OGFntiMTvEZL6G8+VVKqSQBqD5r9nEuWHMeMLLwRgnkjMWEXZcWXv lgig1W3ynvbWiR1cuXWOlQ7nodC6ix4g59N72lRZKCiZYsUHVMYaS5vyXz/qT/lWqM tZRM6Q2YYv98VmCjW1vSLzIrTF8m7MfNwz79u6h4= X-Authentication-Warning: raven.nostrum.com: Host ip-108-232-239-173.texas.us.northamericancoax.com [173.239.232.108] claimed to be [10.48.10.6] From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0E850D77-0A50-420D-A4F4-0D426C6D0F1C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Fri, 11 Oct 2019 14:00:41 -0500 In-Reply-To: Cc: John C Klensin , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG To: Alissa Cooper References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <246B8C1AAC97E005097CAF12@PSB> <48E33F75-6458-4CF2-AD3D-7201E7A86EF8@nostrum.com> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 19:01:05 -0000 --Apple-Mail=_0E850D77-0A50-420D-A4F4-0D426C6D0F1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 11, 2019, at 4:07 AM, Alissa Cooper wrote: >=20 > Hi Ben, >=20 >> On Oct 10, 2019, at 5:52 PM, Ben Campbell > wrote: >>=20 >>=20 >>=20 >>> On Oct 10, 2019, at 12:21 AM, John C Klensin > wrote: >>>=20 >>>=20 >>>=20 >>> --On Tuesday, October 8, 2019 21:18 +0200 Barry Leiba >>> > wrote: >>>=20 >>>> ... >>>>> Another difference is that while DISPATCH is mainly >>>>> interesting to people in the ART Area, we can expect >>>>> GENDISPATCH to draw from all areas. We try not to let >>>>> DISPATCH conflict with other ART meetings. How do you >>>>> deconflict GENDISPATCH without it turning into another plenary >>>>> or a standing BoF? >>>>=20 >>>> This is always an issue with Gen Area BoFs and WGs, and this >>>> will be no different. I think the bottom line is that >>>> there'll be a set of people who will want to participate >>>> regularly, and we'll try to accommodate that... there'll be >>>> people who want to parachute in for certain topics, and we'll >>>> do what we can to accommodate that, realizing that it's >>>> harder... and there'll be a lot of people who won't want to >>>> have anything to do with it until a proposal is at a stage >>>> where they strongly support it or object to it, and there's >>>> little we can do to accommodate that. It is what it is, but >>>> it's no different than if we just charter Gen Area WGs without >>>> a DISPATCH-like start. No? >>>=20 >>> Barry, >>>=20 >>> I see one risk with this that I think should be considered and >>> watched for even if the IESG decides to move forward. >>>=20 >>> The IETF has a rather long and difficult history, with only a >>> few exceptions since the POISED and POISSON WGs, of there being >>> two types of process change proposals. One type is >>> enthusiastically welcomed by the IESG. A large fraction of >>> proposals of that type originated within the IESG (or >>> occasionally the IAB) and were pushed at the community rather >>> than being in any sense bottom-up. That is not necessarily bad >>> -- your work (and Thomas's and Harald's) on IANA Considerations >>> is, IMO, one of the more positive examples. Others are not. >>> They, and especially ones that members of the IESG see as a >>> threat to their authority or the way they do things and >>> sometimes as adding work, have tended to vanish. Often they >>> vanish without a trace, with no opportunity for the community to >>> take positions on Last Call, sometimes inconsistent with WG >>> consensus, and usually with very little accountability for >>> individual ADs or the IESG in general. I (and some others) >>> routinely cite NEWTRK as an example but there are others. In >>> many of them, the IESG has insisted that a working group is >>> needed and then refused to create such a working group (or has >>> created one with a charter so narrow or broad as to make >>> progress impossible) as a means of killing the effort. In >>> others, ADs have managed to erect sufficient obstacles and >>> induce enough delays that people simply lose interest. >>> Sometimes that is A Good Thing; often it is a control mechanism >>> that keep particular people or points of view in power and >>> prevent the IETF from evolving and making progress. >>>=20 >>> So, the question about this proposed WG for me is whether it >>> will make those tendencies better and thereby prevent good ideas >>> from getting lost or suppressed. If so, I think it is a great >>> idea. But I also see the risk of its being used to bury work >>> that it out of favor with "the leadership" and doing so in a way >>> that preserves the status quo except when the IESG wishes things >>> to be different) and enables even less transparency and >>> accountability than we have seen in the past. I'd like to see >>> ideas and controls about how to prevent the latter or how to >>> detect it and push back if it starts to occur, and I don't see >>> those in the current draft specification. >>=20 >> Hi John, >>=20 >> This brings up another question in my mind. The ART ADs typically = treat DISPATCH decisions as non-binding recommendations. Likewise, the = ADs may skip DISPATCH and take proposals straight to BoF or even WG = formation if they think it appropriate. >>=20 >> Would GENDISPATCH decisions be treated the same, or would they be = binding on the IESG? I had assumed the former, in the sense that AD = discretion applies to pretty much any working group. Whichever case is = the answer, I think the charter needs to be explicit about it. >=20 > I changed the sentence about RFC 3710 so it now includes the word = =E2=80=9Cdiscretion.=E2=80=9D = https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ = Hi Alissa, That helps. Also, the text about Gen AD discretion that was already = there that I somehow completely failed to read also helps :-) Ben. >=20 > Best, > Alissa >=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> --=20 >> Gendispatch mailing list >> Gendispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/gendispatch = --Apple-Mail=_0E850D77-0A50-420D-A4F4-0D426C6D0F1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 11, 2019, at 4:07 AM, Alissa Cooper <alissa@cooperw.in> = wrote:

Hi Ben,

On Oct 10, 2019, at 5:52 PM, Ben Campbell = <ben@nostrum.com> = wrote:



On = Oct 10, 2019, at 12:21 AM, John C Klensin <john-ietf@jck.com> = wrote:



--On = Tuesday, October 8, 2019 21:18 +0200 Barry Leiba
<barryleiba@computer.org> wrote:

...
Another difference is = that while DISPATCH is mainly
interesting to people in the = ART Area, we can expect
GENDISPATCH to draw from all = areas. We try not to let
DISPATCH conflict with other ART = meetings. How do you
deconflict GENDISPATCH without it = turning into another plenary
or a standing BoF?

This is always an issue with Gen = Area BoFs and WGs, and this
will be no different.  I = think the bottom line is that
there'll be a set of people = who will want to participate
regularly, and we'll try to = accommodate that... there'll be
people who want to = parachute in for certain topics, and we'll
do what we can = to accommodate that, realizing that it's
harder... and = there'll be a lot of people who won't want to
have = anything to do with it until a proposal is at a stage
where = they strongly support it or object to it, and there's
little= we can do to accommodate that.  It is what it is, but
it's no different than if we just charter Gen Area WGs = without
a DISPATCH-like start.  No?

Barry,

I see one risk with this that I think should be considered = and
watched for even if the IESG decides to move = forward.

The IETF has a rather long and = difficult history, with only a
few exceptions since the = POISED and POISSON WGs, of there being
two types of = process change proposals.  One type is
enthusiastically= welcomed by the IESG.  A large fraction  of
proposals of that type originated within the IESG (or
occasionally the IAB) and were pushed at the community = rather
than being in any sense bottom-up.  That is = not necessarily bad
-- your work (and Thomas's and = Harald's) on IANA Considerations
is, IMO, one of the more = positive examples.   Others are not.
They, and = especially ones that members of the IESG see as a
threat = to their authority or the way they do things and
sometimes = as adding work, have tended to vanish.  Often they
vanish without a trace, with no opportunity for the community = to
take positions on Last Call, sometimes inconsistent = with WG
consensus, and usually with very little = accountability for
individual ADs or the IESG in general. =  I (and some others)
routinely cite NEWTRK as an = example but there are others.  In
many of them, the = IESG has insisted that a working group is
needed and then = refused to create such a working group (or has
created one = with a charter so narrow or broad as to make
progress = impossible) as a means of killing the effort.  In
others, ADs have managed to erect sufficient obstacles and
induce enough delays that people simply lose interest.
Sometimes that is A Good Thing; often it is a control = mechanism
that keep particular people or points of view in = power and
prevent the IETF from evolving and making = progress.

So, the question about this = proposed WG for me is whether it
will make those = tendencies better and thereby prevent good ideas
from = getting lost or suppressed.   If so, I think it is a great
idea.   But I also see the risk of its being used = to bury work
that it out of favor with "the leadership" = and doing so in a way
that preserves the status quo except = when the IESG wishes things
to be different) and enables = even less transparency and
accountability than we have = seen in the past.  I'd like to see
ideas and controls = about how to prevent the latter or how to
detect it and = push back if it starts to occur, and I don't see
those in = the current draft specification.

Hi John,

This brings up another question = in my mind. The ART ADs typically treat DISPATCH decisions as = non-binding recommendations. Likewise, the ADs may skip DISPATCH and = take proposals straight to BoF or even WG formation if they think it = appropriate.

Would = GENDISPATCH decisions be treated the same, or would they be binding on = the IESG? I had assumed the former, in the sense that AD discretion = applies to pretty much any working group. Whichever case is the answer, = I think the charter needs to be explicit about it.

I changed the sentence about RFC 3710 so it now includes the = word =E2=80=9Cdiscretion.=E2=80=9D https://datatracker.ietf.org/doc/charter-ietf-gendispatch/<= /div>

Hi = Alissa,

That helps. Also, the text = about Gen AD discretion that was already there that I somehow completely = failed to read also helps :-)

Ben.



Best,
Alissa


Thanks!

Ben.

-- Gendispatch mailing = list
Gendispatch@ietf.org
https://www.ietf.org/mailman/listinfo/gendispatch


= --Apple-Mail=_0E850D77-0A50-420D-A4F4-0D426C6D0F1C-- From nobody Fri Oct 11 12:13:31 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58502120096; Fri, 11 Oct 2019 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 IWggXHfy6fJQ; Fri, 11 Oct 2019 12:13:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5ABF4120114; Fri, 11 Oct 2019 12:13:08 -0700 (PDT) Received: from [10.48.10.6] (ip-108-232-239-173.texas.us.northamericancoax.com [173.239.232.108]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x9BJD017065929 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Oct 2019 14:13:01 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1570821182; bh=bVv4p/yGrWmp9GAGnjM/7KQIYQG8MYCGpeX2OMhmMe8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tjzJDNsSq5NvA8yHTsNcaZJMqmM2ommhVHHIMnLDYfh6ZXH6RP4B7jooD1EyOP0K5 6t4yJ0vSs6P/wCz0/E9znhsSG24muJccuZGdQPcvyUCKEWZ5MsOoSJC2NZIH4EHOIR M0tabH0QhsSy7WDrVSgoAHdNF1bhDA+b2GFXjl80= X-Authentication-Warning: raven.nostrum.com: Host ip-108-232-239-173.texas.us.northamericancoax.com [173.239.232.108] claimed to be [10.48.10.6] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Ben Campbell In-Reply-To: <18383AE8-9AF2-4C93-8598-EF33F7E49A4B@cooperw.in> Date: Fri, 11 Oct 2019 14:12:59 -0500 Cc: Mark Nottingham , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <6B306CEB-3DC3-4315-ADF3-56A8FCE4225E@nostrum.com> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> <18383AE8-9AF2-4C93-8598-EF33F7E49A4B@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 19:13:28 -0000 > On Oct 11, 2019, at 4:10 AM, Alissa Cooper wrote: >=20 > Hi Ben, >=20 >> On Oct 10, 2019, at 6:05 PM, Ben Campbell wrote: >>=20 >> Here=E2=80=99s an attempt to distill my concern a little better: >>=20 >> The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of = as a triage process. Triage makes sense when you don=E2=80=99t have the = time and resources to address every problem and have to pick and choose = where you can have the most impact. If you do have time and resources to = address everything, then triage is just a process bump.=20 >>=20 >> Do we believe that GEN area proposals will routinely exceed our = capacity to discuss them? If so, do we think that will continue to be = true for the foreseeable future? (I assume this is intended to be a = long-lived wg). >=20 > I guess I see the question differently. If there are people in the = community who are willing to manage discussions about process proposals = while they=E2=80=99re in formation (i.e., people willing to chair this = WG), that seems like a better arrangement than the current one both from = the perspective of being more community-led and from the perspective of = the other time commitments that the IESG has. If the WG isn=E2=80=99t = busy or meeting all the time, that=E2=80=99s fine =E2=80=94 it will = still be nice to have it there for times when process proposals do come = up and inspire discussion. I think I=E2=80=99ve been unclear in my concern. I have no objection to = having a working group for discussion of proposals to improve processes. = I think that=E2=80=99s a good idea. My question is about whether such = working group should be limited to the dispatch process. Certainly there may be case where there it is appropriate dispatch work = to some other venue, spin up a new wg for a proposal, etc. But I wonder = why we need to decide in advance that work on a proposal will cannot be = completed by this group. Especially when it seems likely that the people = working on a proposal will often be the same whether the work happens in = gendispatch or somewhere else. Thanks! Ben. >=20 From nobody Fri Oct 11 12:22:53 2019 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F2120018; Fri, 11 Oct 2019 12:22:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, alissa@cooperw.in, gendispatch@ietf.org, gendispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157082177087.29366.17344884067434508017.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2019 12:22:50 -0700 Archived-At: Subject: [Gendispatch] gendispatch - New Meeting Session Request for IETF 106 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 19:22:51 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the gendispatch working group. --------------------------------------------------------- Working Group Name: General Area Dispatch Area Name: General Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 75 Conflicts to Avoid: Technology Overlap: artarea genarea cbor ace core lake quic dprive anima opsawg spring tls abcd wpack webtrans txauth tmrid raw mathmesh People who must be present: Pete Resnick Alissa Cooper Francesca Palombini Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 11 18:12:32 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0C1120059; Fri, 11 Oct 2019 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 40_AYKr3uFg0; Fri, 11 Oct 2019 18:12:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 243111200B6; Fri, 11 Oct 2019 18:12:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6A0CD6601D7; Sat, 12 Oct 2019 04:12:15 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjZLZBuuzxkQ; Sat, 12 Oct 2019 04:12:12 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 7C83E66013D; Sat, 12 Oct 2019 04:12:12 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Sat, 12 Oct 2019 04:12:11 +0300 Cc: gendispatch@ietf.org, IETF discussion list , IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> To: Brian E Carpenter , Alissa Cooper X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 01:12:21 -0000 Brian, Alissa, > I think that we have never really had a problem handling minor process = fixes. That's why we have so many process-related RFCs, in fact. For = those, GENDISPATCH will clearly help us do the triage a bit more = systematically, and that is a Good Thing.=20 For what it is worth, I=E2=80=99m in favour of setting up this new = group. I agree with Brian=E2=80=99s assessment above; when it comes to = non-technical work, we=E2=80=99ve certainly been able to do many small = changes. Actually, unlike Brian I think we=E2=80=99ve also been able to = do some bigger things as well (IASA 2.0 comes to mind as a recent = example) but maybe some of those are more under the topic of = administration rather than process work. Anyway, I think what this new working group will bring is a bit more = structure and additional people and more eyes on topics that have = traditionally too reliant on GEN AD sponsorship and IESG discussions. = That=E2=80=99s great, and an improvement (even if we previously were = able to produce process RFCs as well). This new working group does not remove all problems from this space, of = course, and one of the continuing challenges is to get the people who do = normal IETF work to know and care about process issues. Bringing things = up on plenaries etc will be useful, as well as on ietf@ietf (but = clearly, the set of people on that !=3D the set of people doing IETF = work). Also, +1 to what Mirja wrote. Jari From nobody Sat Oct 12 07:36:05 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EB512008F for ; Sat, 12 Oct 2019 07:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 (1024-bit key) header.d=ducksong.com header.b=Sm1ydX81; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=TtM176ZX 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 pWEUXnbCplFW for ; Sat, 12 Oct 2019 07:36:00 -0700 (PDT) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 0FF87120019 for ; Sat, 12 Oct 2019 07:36:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570890959; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RMoecwUYcCoFkV0k29ABhUN639O7ZSKPpL1X09U1eGfT8JIE3nFCtCQuMJZyccgavC3TMepgv7qzP YtRNh3lm4A1zOubf0Nk94t31i2bTQ1aVFAoZt/zeiAacD88ynUKk2cKncjc73Bq9LajIv6zZL5txqc 9pIrgc+6LgAnsNeuS+0KOtE1T67iyTNurZzxYHAXmPNgh3cre0Alrwh28SBS0GQt8AlpLrvMSYqLoi pjV23ra6w437WqI4G5gxiLJ7yhWRS/nQ6t1Qs1uXJAuyZk/tK+r0o/15mYZ8cFDXvgY1XPlWyUizpG RMH4cUb2Ph6dYOBoez1JbvKjmOUg/8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=M3LGcF4V23W8ADI7Jk4uXtxMm1Ej8lMzRm5rOuLSEUo=; b=GcnKeszVfJNXyjbO7tVtWZVU8KC6J1XB6SGyJ7GGJn/u9rVStTFw6TRKew2HFh9Pq15IYCJ8/Y0yt JUZTTk5uhoxuemNeV74ukZ3JxP4+4qF5/cqKIMLkm8CrItTv3ZH9wV6XKLcY06vANrEinlNx0HPkbY QOhGy+nzeEa94r1ofmHNzHCMJTr/7TfFzDEe8NU80tu/G3E6tNDO+MSDb1nxMqEvgapZ2d9lgzyJ7i pi+uSn31nI5A9TWyTkv/C5WZ7LBgUpDV8rNAW+05AfB6Rav3Kk9eVVMB5qx88AHVdLSRPbyoccshIH AMUoxXUMig3WY/tjG8fMAqaxipJesoA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.47; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=M3LGcF4V23W8ADI7Jk4uXtxMm1Ej8lMzRm5rOuLSEUo=; b=Sm1ydX81FEmgVrCE5z4gbKzBlUQyBtORndMR2C4vZaiomdINPRnnblnRcecXaFU89QA/l0Nwr9/EL c0UTxN2PC89emDsQgWICJ6j6CVF36p1RuYPU5i43bVAYOkohW6lLqCd95svYM8lLU6DT7lng9+H81U LDthYN3QekQvXvMo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=M3LGcF4V23W8ADI7Jk4uXtxMm1Ej8lMzRm5rOuLSEUo=; b=TtM176ZX3bgnNqgo3bqRmOCpcypj+0ij3h/rrXjNyyt+2i23+fNrkBjSDF9e/YRWywHl+lj0esglD 6ayifIMNsPB1ZAzpl0wyTkq2GJgxmhGPNPzR+ISYNDK6icC6bFiEms2yvcZcOYDRkTdmmh1SHXyatH 5NKSOdjrjIj2YCCkRJQ87aF6sPCqSXZ2+nQCkmWpjdNymXR9LtTkv/GVlDua2XmnVXK5UKEP5dz/3R NfHZpuJdnR/ezkwSUKxlV964W7X1x8LbriOXkyrDim5tdhbR7Racdy5bZMv1yYvSyTXrqFk76O8B3O TorDQUcq+om3/jEsVJrbrQ6MXPidirw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 9a2b4cff-ecfd-11e9-85ed-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.47 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f47.google.com (unknown [209.85.210.47]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 9a2b4cff-ecfd-11e9-85ed-13b9aae3a1d2; Sat, 12 Oct 2019 14:35:58 +0000 (UTC) Received: by mail-ot1-f47.google.com with SMTP id o44so10359248ota.10; Sat, 12 Oct 2019 07:35:57 -0700 (PDT) X-Gm-Message-State: APjAAAVAGQZKeQOSs3AkbHl50YDyHOCp0OX8U4zW3hEDAz4Or3gY0fo7 mSqKcqGrgbiyz8qA8qYn/lAJgc2iCm328We3iw8= X-Google-Smtp-Source: APXvYqxav297ucB6xWKZv+3tvkhF2Awo2igVaEvwTNaca9G2FRdgU5uJa7RCYlr0EbpMud55Bq8eTgSztqyFViqusnw= X-Received: by 2002:a9d:66d2:: with SMTP id t18mr1357724otm.154.1570890956711; Sat, 12 Oct 2019 07:35:56 -0700 (PDT) MIME-Version: 1.0 References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> In-Reply-To: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Sat, 12 Oct 2019 10:35:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: IETF Discussion Mailing List Cc: gendispatch@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000074ab0b0594b78d3c" Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 14:36:03 -0000 --00000000000074ab0b0594b78d3c Content-Type: text/plain; charset="UTF-8" Alissa, This is a good idea that I support. Specific GEN proposals will benefit from a more focused space than the current mechanisms allow. Thanks for putting this together. -Patrick On Thu, Sep 26, 2019 at 6:46 PM The IESG wrote: > A new IETF WG has been proposed in the General Area. The IESG has not made > any determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by 2019-10-11. > > General Area Dispatch (gendispatch) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Francesca Palombini > Pete Resnick > > Assigned Area Director: > Alissa Cooper > > General Area Directors: > Alissa Cooper > > Mailing list: > Address: gendispatch@ietf.org > To subscribe: > Archive: > > Group page: https://datatracker.ietf.org/group/gendispatch/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ > > The GENDISPATCH working group is a DISPATCH-style working group (see RFC > 7957) chartered to consider proposals for new work in the GEN area, > including > proposals for changes or improvements to the IETF process and process > documents. The working group is chartered to identify, or help create, an > appropriate venue for the work. The working group will not consider any > technical standardization work. > > Guiding principles for the proposed new work include: > > 1. Providing a clear problem statement, historical context, motivation, and > deliverables for the proposed new work. > > 2. Ensuring there has been adequate mailing list discussion reflecting > sufficient interest, individuals have expressed a willingness to contribute > (if appropriate given the subject matter of the proposal) and there is WG > consensus before new work is dispatched. > > 3. Looking for and identifying commonalities and overlap amongst published > or > ongoing work in the GEN area, within the IESG, or within the IETF LLC. > > Options for handling new work include: > > - Directing the work to an existing WG. > > - Developing a proposal for a BOF. > > - Developing a charter for a new WG. > > - Making recommendations that documents be AD-sponsored (which ADs may or > may > not choose to follow). > > - Requesting that the the IESG or the IETF LLC consider taking up the work. > > - Deferring the decision for the new work. > > - Rejecting the new work. > > If the group decides that a particular topic needs to be addressed by a new > WG, the normal IETF chartering process will be followed, including, for > instance, IETF-wide review of the proposed charter. Proposals for large > work > efforts SHOULD lead to a BOF where the topic can be discussed in front of > the > entire IETF community. Documents progressed as AD-sponsored would typically > include those that are extremely simple or make minor updates to existing > process documents. > > Proposed new work may be deferred in cases where the WG does not have > enough > information for the chairs to determine consensus. New work may be rejected > in cases where there is not sufficient WG interest or the proposal has been > considered and rejected in the past, unless a substantially revised > proposal > is put forth, including compelling new reasons for accepting the work. > > A major objective of the GENDISPATCH WG is to provide timely, clear > dispositions of new efforts. Thus, where there is consensus to take on new > work, the WG will strive to quickly find a home for it. While most new work > in the GEN area is expected to be considered in the GENDISPATCH working > group, there may be times where that is not appropriate. At the discretion > of > the GEN AD, new efforts may follow other paths. For example, work may go > directly to a BOF, may be initiated in other working groups when it clearly > belongs in that group, or may be directly AD-sponsored. > > Another major objective of the GENDISPATCH WG is to streamline how the IETF > community considers process improvements. Community discussions about > process > suggestions that begin on other mailing lists, including ietf@ietf.org, > will > be redirected to the GENDISPATCH mailing list where they will be > facilitated > by the WG chairs. Proponents of process improvements will be encouraged to > craft concrete proposals for discussion on the GENDISPATCH mailing list, > with > the goal of producing a concrete outcome in bounded time. Direct requests > to > the IESG may also, after proper consideration, be redirected to the WG. For > proposals to be considered by the WG they will be expected to meet guiding > principle #1 above. > > The existence of this working group does not change the IESG's > responsibilities as described in RFC 3710. Work related to the IAB, IRTF, > and > RFC Editor processes is out of scope. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > --00000000000074ab0b0594b78d3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alissa,

This is a good idea that I supp= ort. Specific GEN proposals will benefit from a more focused space than the= current mechanisms allow. Thanks for putting this together.

=
-Patrick


On Thu, Sep 26, 2019 at 6:46 PM The= IESG <iesg-secretary@ietf.or= g> wrote:
A new IETF WG has been proposed in the General Area. The IESG has not made=
any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the<= br> IESG mailing list (iesg@= ietf.org) by 2019-10-11.

General Area Dispatch (gendispatch)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Francesca Palombini <francesca.palombini@ericsson.com>
=C2=A0 Pete Resnick <resnick@episteme.net>

Assigned Area Director:
=C2=A0 Alissa Cooper <alissa@cooperw.in>

General Area Directors:
=C2=A0 Alissa Cooper <alissa@cooperw.in>

Mailing list:
=C2=A0 Address: g= endispatch@ietf.org
=C2=A0 To subscribe:
=C2=A0 Archive:

Group page: https://datatracker.ietf.org/group/gendis= patch/

Charter: https://datatracker.ietf.org/doc/= charter-ietf-gendispatch/

The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, includi= ng
proposals for changes or improvements to the IETF process and process
documents. The working group is chartered to identify, or help create, an appropriate venue for the work. The working group will not consider any
technical standardization work.

Guiding principles for the proposed new work include:

1. Providing a clear problem statement, historical context, motivation, and=
deliverables for the proposed new work.

2. Ensuring there has been adequate mailing list discussion reflecting
sufficient interest, individuals have expressed a willingness to contribute=
(if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched.

3. Looking for and identifying commonalities and overlap amongst published = or
ongoing work in the GEN area, within the IESG, or within the IETF LLC.

Options for handling new work include:

- Directing the work to an existing WG.

- Developing a proposal for a BOF.

- Developing a charter for a new WG.

- Making recommendations that documents be AD-sponsored (which ADs may or m= ay
not choose to follow).

- Requesting that the the IESG or the IETF LLC consider taking up the work.=

- Deferring the decision for the new work.

- Rejecting the new work.

If the group decides that a particular topic needs to be addressed by a new=
WG, the normal IETF chartering process will be followed, including, for
instance, IETF-wide review of the proposed charter. Proposals for large wor= k
efforts SHOULD lead to a BOF where the topic can be discussed in front of t= he
entire IETF community. Documents progressed as AD-sponsored would typically=
include those that are extremely simple or make minor updates to existing process documents.

Proposed new work may be deferred in cases where the WG does not have enoug= h
information for the chairs to determine consensus. New work may be rejected=
in cases where there is not sufficient WG interest or the proposal has been=
considered and rejected in the past, unless a substantially revised proposa= l
is put forth, including compelling new reasons for accepting the work.

A major objective of the GENDISPATCH WG is to provide timely, clear
dispositions of new efforts. Thus, where there is consensus to take on new<= br> work, the WG will strive to quickly find a home for it. While most new work=
in the GEN area is expected to be considered in the GENDISPATCH working
group, there may be times where that is not appropriate. At the discretion = of
the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly=
belongs in that group, or may be directly AD-sponsored.

Another major objective of the GENDISPATCH WG is to streamline how the IETF=
community considers process improvements. Community discussions about proce= ss
suggestions that begin on other mailing lists, including ietf@ietf.org, will
be redirected to the GENDISPATCH mailing list where they will be facilitate= d
by the WG chairs. Proponents of process improvements will be encouraged to<= br> craft concrete proposals for discussion on the GENDISPATCH mailing list, wi= th
the goal of producing a concrete outcome in bounded time. Direct requests t= o
the IESG may also, after proper consideration, be redirected to the WG. For=
proposals to be considered by the WG they will be expected to meet guiding<= br> principle #1 above.

The existence of this working group does not change the IESG's
responsibilities as described in RFC 3710. Work related to the IAB, IRTF, a= nd
RFC Editor processes is out of scope.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce

--00000000000074ab0b0594b78d3c-- From nobody Sat Oct 12 13:23:05 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D361200A4; Sat, 12 Oct 2019 13:23:03 -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 n_1lkUAFskKi; Sat, 12 Oct 2019 13:23:01 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBD512006A; Sat, 12 Oct 2019 13:23:00 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 0A7AB1F456; Sat, 12 Oct 2019 20:22:58 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 024DC834; Sat, 12 Oct 2019 22:22:56 +0200 (CEST) From: Michael Richardson To: Jari Arkko cc: Brian E Carpenter , Alissa Cooper , gendispatch@ietf.org, IETF discussion list , IESG In-reply-to: References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> Comments: In-reply-to Jari Arkko message dated "Sat, 12 Oct 2019 04:12:11 +0300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31640.1570911775.1@dooku.sandelman.ca> Date: Sat, 12 Oct 2019 22:22:55 +0200 Message-ID: <31641.1570911775@dooku.sandelman.ca> Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 20:23:03 -0000 Not sure who wrote this: >> I think that we have never really had a problem handling minor process >> fixes. That's why we have so many process-related RFCs, in fact. For >> those, GENDISPATCH will clearly help us do the triage a bit more >> systematically, and that is a Good Thing. Is the purpose of GENDISPATCH to deal with minor process exceptions, or fixes? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Mon Oct 14 05:18:00 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09D120274; Mon, 14 Oct 2019 05:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=HYOejhlU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qRIpFQCN 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 PPffnw--dxnH; Mon, 14 Oct 2019 05:17:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2BF120255; Mon, 14 Oct 2019 05:17:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2B79922245; Mon, 14 Oct 2019 08:17:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 14 Oct 2019 08:17:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=E mnxDPVB41LHsjhqAXf7INivIII1+ivJ7MPNDhtsHj8=; b=HYOejhlUnaBjvJx+j PBTkKDcUZRw5c2BWY2euUCwWEehfxN63NC65d6bSEkIqJp5DwqqrY/YjgC2HGsmq wEEGHy/0ccLfrvrMQsSMEMDAQ8rcYHiqgRQfGvHqMfKifCpmJ4YyuwqMfrJPIXYO e9UvP9ZO7uU3cU/LopuvqA+M06vyT2MeM+u+ZPfl9iIV0/wf8kTB91bK2fiiMBKp WTfHDBl3ODaphk5d/6/pUWN42yfHqZ4RSGCMag2NT5TUuGMGpfg2CzFd406lQy3U MxBxrXCNuYzQlxMkIFqn+UHAugjqHeU8jfHT7GC0rO8ZUMNQIicNE/cqFC6eV21+ SqHbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=EmnxDPVB41LHsjhqAXf7INivIII1+ivJ7MPNDhtsH j8=; b=qRIpFQCNGnJ33vK8RC2zwS0SM2dMlUeEPhElOdCA/wHxX2/pbv97eaWrI 2uCVW2bZ31hz8YGNaiuuxpOGSWVG5AzUzhQ2aNutrMoi4WZLe51o47FDW8FJcln4 S8BupqBJaiRBY0RwK8cmN2PZMrdpO+ikJVyhMNVvzirnPSELbblKTDtBHoPfLrpf yBWJx2J67UwZ7OIJ6D+40CNXdU/a+AajtJzhYpXSihUTaDiIkiBYVGGdIeh/Z8Gs AzAqK/7Ibf+LvtIoxC+Y87D+LH8rRLyec4ViMPNAjrAutlAnbTe2dXcEvtc3cnAM nIBaBfRiAvI1wnF3morodW2KPLlCQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjedugdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppedvfe drvddtrddvgeehrddvgeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrges tghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.0.162] (ec2-23-20-245-243.compute-1.amazonaws.com [23.20.245.243]) by mail.messagingengine.com (Postfix) with ESMTPA id B6246D6005E; Mon, 14 Oct 2019 08:17:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <6B306CEB-3DC3-4315-ADF3-56A8FCE4225E@nostrum.com> Date: Mon, 14 Oct 2019 08:17:52 -0400 Cc: Mark Nottingham , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <338E53C5-08C7-470A-A7A9-EF548B00F320@cooperw.in> References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> <18383AE8-9AF2-4C93-8598-EF33F7E49A4B@cooperw.in> <6B306CEB-3DC3-4315-ADF3-56A8FCE4225E@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 12:17:58 -0000 Hi Ben, > On Oct 11, 2019, at 3:12 PM, Ben Campbell wrote: >=20 >=20 >=20 >> On Oct 11, 2019, at 4:10 AM, Alissa Cooper wrote: >>=20 >> Hi Ben, >>=20 >>> On Oct 10, 2019, at 6:05 PM, Ben Campbell wrote: >>>=20 >>> Here=E2=80=99s an attempt to distill my concern a little better: >>>=20 >>> The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of = as a triage process. Triage makes sense when you don=E2=80=99t have the = time and resources to address every problem and have to pick and choose = where you can have the most impact. If you do have time and resources to = address everything, then triage is just a process bump.=20 >>>=20 >>> Do we believe that GEN area proposals will routinely exceed our = capacity to discuss them? If so, do we think that will continue to be = true for the foreseeable future? (I assume this is intended to be a = long-lived wg). >>=20 >> I guess I see the question differently. If there are people in the = community who are willing to manage discussions about process proposals = while they=E2=80=99re in formation (i.e., people willing to chair this = WG), that seems like a better arrangement than the current one both from = the perspective of being more community-led and from the perspective of = the other time commitments that the IESG has. If the WG isn=E2=80=99t = busy or meeting all the time, that=E2=80=99s fine =E2=80=94 it will = still be nice to have it there for times when process proposals do come = up and inspire discussion. >=20 > I think I=E2=80=99ve been unclear in my concern. I have no objection = to having a working group for discussion of proposals to improve = processes. I think that=E2=80=99s a good idea. My question is about = whether such working group should be limited to the dispatch process. >=20 > Certainly there may be case where there it is appropriate dispatch = work to some other venue, spin up a new wg for a proposal, etc. But I = wonder why we need to decide in advance that work on a proposal will = cannot be completed by this group. Especially when it seems likely that = the people working on a proposal will often be the same whether the work = happens in gendispatch or somewhere else. Ah, got it. This is a good question. Perhaps we can try it in = dispatch-style for awhile and see if we=E2=80=99re often arriving at an = outcome where it seems like just processing a document in the WG would = be the most logical thing to do. If so, a re-charter to allow that would = be possible. I was a little hesitant to jump straight to having a = General Area Working Group; the dispatch-style group seemed like it = could be a useful intermediate step. Alissa >=20 > Thanks! >=20 > Ben. >>=20 >=20 From nobody Wed Oct 16 19:46:06 2019 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9149D1201CE; Wed, 16 Oct 2019 19:46:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: gendispatch-chairs@ietf.org, gendispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157128036452.9824.5867642744342377809.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 19:46:04 -0700 Archived-At: Subject: [Gendispatch] Benjamin Kaduk's No Objection on charter-ietf-gendispatch-00-09: (with COMMENT) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 02:46:05 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-gendispatch-00-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Guiding principles for the proposed new work include: [...] 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. nit: this list does not have a parallel construction; perhaps "enough indivdiuals" would help? Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. Can work be rejected because the WG thinks it is a bad idea? (Is that supposed to be part of "not sufficient WG interest"?) From nobody Thu Oct 17 06:24:41 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F455120144; Thu, 17 Oct 2019 06:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=hO7UvXGo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VRblUyq2 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 emczAUC0vzIh; Thu, 17 Oct 2019 06:24:30 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7B71200E3; Thu, 17 Oct 2019 06:24:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3F3F0492; Thu, 17 Oct 2019 09:24:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 17 Oct 2019 09:24:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=y 9gR4uqfDsh9uMYdjS37Qk7Qupg5Vbsf9vhQ8cfHrKU=; b=hO7UvXGokTJmYc+AV bZPSZF+Hle/LMXkroTGVyWvixeum71ZlS/jjWjdCwHehPzH75iUNba0Fdcd8SipO D3wouPY+M8KKdWJlLmTWw7XXz/hyuOLED0lWLHd6+8pyUHZoD4qTyPBy+MiReOna B7feuyJ+eElN0b9VI4nHGPZfYNvvndl2iA7/JjpvEXs82psCurhM+AfwTaIleRP7 Vhud8ihCdd50EuOdwUPNjCENsgMCj9LeZ3cq4wkM3NZBvOBgYeUmEMEUdNgsnwhN ASgDmoUpScnv3pqu84QCP0OzQTrg4gksLupXFWHMm0OM4nU7QhiVw7lMfBPNWJbG vLViw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=y9gR4uqfDsh9uMYdjS37Qk7Qupg5Vbsf9vhQ8cfHr KU=; b=VRblUyq23OnyXYQW7hguPUwF6GQJmLZrZ6V9cMCM0OK7lERzi1/xue4Yn Ni0Isp0d0/XU47DKv1jNIuU1wZaXfheQOEYCDD/ZFDe7m5mbih4o5wx07XC5Cj0K 6kN4ZYXOWD9SoG2o7MroM0mp6b32xi4sc72povTlINJFHBR2Z1atPRbRyC+1+FuH N9fpOcIl9nxd+w5WkSYYs0ppox6jI2S7jIBM+B0dT9M7SVhKAyqhmK7DXjy+xKY0 rUKEj2NSh8uZOnQuKrJZjjKESBjLKqOmjfbJLgfP6F7UO3O70vS4LzzuP7EVyGRd o6xPBwWqmsvFC0K2x2xxHOui1/I3Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeejgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F88B80062; Thu, 17 Oct 2019 09:24:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157128036452.9824.5867642744342377809.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2019 09:24:21 -0400 Cc: IESG , gendispatch@ietf.org, gendispatch-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4FFE0833-4EDA-4AA0-A937-739A784851A2@cooperw.in> References: <157128036452.9824.5867642744342377809.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Gendispatch] Benjamin Kaduk's No Objection on charter-ietf-gendispatch-00-09: (with COMMENT) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 13:24:33 -0000 Hi Ben, > On Oct 16, 2019, at 10:46 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > charter-ietf-gendispatch-00-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Guiding principles for the proposed new work include: > [...] > 2. Ensuring there has been adequate mailing list discussion = reflecting > sufficient interest, individuals have expressed a willingness to = contribute (if > appropriate given the subject matter of the proposal) and there is WG = consensus > before new work is dispatched. >=20 > nit: this list does not have a parallel construction; perhaps "enough > indivdiuals" would help? Fixed. Thanks. >=20 > Proposed new work may be deferred in cases where the WG does not have = enough > information for the chairs to determine consensus. New work may be = rejected in > cases where there is not sufficient WG interest or the proposal has = been > considered and rejected in the past, unless a substantially revised = proposal is > put forth, including compelling new reasons for accepting the work. >=20 > Can work be rejected because the WG thinks it is a bad idea? (Is that > supposed to be part of "not sufficient WG interest=E2=80=9D?) I do think this is supposed to be part of sufficient WG interest. Best, Alissa >=20 >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Fri Oct 18 09:31:29 2019 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1A41200F9; Fri, 18 Oct 2019 09:31:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , gendispatch@ietf.org, gendispatch-chairs@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157141628250.3985.4952569228703796752.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2019 09:31:22 -0700 Archived-At: Subject: [Gendispatch] WG Action: Formed General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 16:31:22 -0000 A new IETF WG has been formed in the General Area. For additional information, please contact the Area Directors or the WG Chairs. General Area Dispatch (gendispatch) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Francesca Palombini Pete Resnick Assigned Area Director: Alissa Cooper General Area Directors: Alissa Cooper Mailing list: Address: gendispatch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/gendispatch Archive: https://mailarchive.ietf.org/arch/browse/gendispatch/ Group page: https://datatracker.ietf.org/group/gendispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, including proposals for changes or improvements to the IETF process and process documents. The working group is chartered to identify, or help create, an appropriate venue for the work. The working group will not consider any technical standardization work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, historical context, motivation, and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, enough individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing work in the GEN area, within the IESG, or within the IETF LLC. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - Requesting that the the IESG or the IETF LLC consider taking up the work. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Documents progressed as AD-sponsored would typically include those that are extremely simple or make minor updates to existing process documents. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the GENDISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the GEN area is expected to be considered in the GENDISPATCH working group, there may be times where that is not appropriate. At the discretion of the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD-sponsored. Another major objective of the GENDISPATCH WG is to streamline how the IETF community considers process improvements. Community discussions about process suggestions that begin on other mailing lists, including ietf@ietf.org, will be redirected to the GENDISPATCH mailing list where they will be facilitated by the WG chairs. Proponents of process improvements will be encouraged to craft concrete proposals for discussion on the GENDISPATCH mailing list, with the goal of producing a concrete outcome in bounded time. Direct requests to the IESG may also, after proper consideration, be redirected to the WG. For proposals to be considered by the WG they will be expected to meet guiding principle #1 above. The existence of this working group does not change the IESG's responsibilities and discretion as described in RFC 3710. Work related to the IAB, IRTF, and RFC Editor processes is out of scope. A review of the efficacy of this working group will be undertaken 18-24 months after its chartering. From nobody Thu Oct 24 20:02:10 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83B1200A3; Thu, 24 Oct 2019 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0dC_ho0FZQo9; Thu, 24 Oct 2019 20:02:05 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 AA1D61200EF; Thu, 24 Oct 2019 20:02:04 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id c4so919056lja.11; Thu, 24 Oct 2019 20:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jEXBPpnC/JBa885/memVpKFm3jYUYd0s7D7BKloEU4o=; b=glQ0Ve8A0dBnlSScl6zhJwo6FcH33uL6Mrr+eUXddFvCAowQ0NZEHc+9cTiYgcrkH2 SfiMl5tUmZQ5KnJD6Ul1FwoLLEuKRpeIxlY/6fJl89XeBoVkmdT3EXrY3ICwM83p4CYV 67d71Af8i0NHZJ1/U2ZlKzpnHNWrlQ5p7bvkE3joTVN8D39RoH9JrSq5QOGd8b/b9PVm GvOmZ0q+bcmoimvONSr8uRrPpkT7mNsdqEoRf8uwSXv9RL6hIUkjKJy4XeW40lulvUjV /VepIr+jmmSldNJiYtyiso8fQCfVw/wMoXzawTWIlVoI41GUyAC5fpY0UDbM4aXhC24U vZyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jEXBPpnC/JBa885/memVpKFm3jYUYd0s7D7BKloEU4o=; b=TubJNlPwSeg7lDkjrJc0Ktq3f+8yGY+waFyTgK/gQjPoDn0GzwZ5lB48az4b0nbSfU tBbrhw2GOqZHcBGMGbncld/NXBIw20M5SeNNzQDVr5JgFVe3sXsd1gnZfvgKQiQ7TTZ0 1i0yBNOj1cCNTsv4NpZYjOwN6+HEtyanemuSnmYbmTRIGVG/+T2dfQML4juFHl/rJdDp dINWvVWlOZ9h5yXUq96LuB7hjNcKaLH8j4cIhdL80aYa1mEtSnE1P8C2o0CfB+5Ciq/p 0xj7oyQV2hMOTmM4uJuJXbMDonRGVwQ/UYSQE00Zo8t+Y3hUsQmgU/rzi0WQNfmvAJZx S8Vw== X-Gm-Message-State: APjAAAUUiwEZdNu3yHLVojWdbHzHYCuhzjuTxd91RNcxXpVKHLWcmpYb gwfoaVIgipuWkwzJRsQbeoDNwIYpGSw87NRsYUQ= X-Google-Smtp-Source: APXvYqyxxqMdoc9laOFT6kuOsECfgyGAVgIdao/9nzfVVLFQeNHvrikaP53O/055qOJsIZ+VFG77gCktQjTzQg/HPYo= X-Received: by 2002:a2e:8616:: with SMTP id a22mr15906lji.30.1571972522742; Thu, 24 Oct 2019 20:02:02 -0700 (PDT) MIME-Version: 1.0 References: <156953786511.31837.12069537821662045851.idtracker@ietfa.amsl.com> <8A15D8AF-6B1A-42A0-85CE-DF861E73C1C2@nostrum.com> <6CC7893B-7A6C-4A6A-9AB4-9C62A4E1777A@nostrum.com> <6F6819D9-E681-4247-8C19-F87709ADB1CA@mnot.net> <2DE4AAEA-13A0-4D49-AE3E-8ACCD81BF49E@nostrum.com> <2E4933D9-ECD0-436A-9ADA-5EF6C6470C01@nostrum.com> <18383AE8-9AF2-4C93-8598-EF33F7E49A4B@cooperw.in> <6B306CEB-3DC3-4315-ADF3-56A8FCE4225E@nostrum.com> <338E53C5-08C7-470A-A7A9-EF548B00F320@cooperw.in> In-Reply-To: <338E53C5-08C7-470A-A7A9-EF548B00F320@cooperw.in> From: Spencer Dawkins at IETF Date: Thu, 24 Oct 2019 22:01:34 -0500 Message-ID: To: Alissa Cooper Cc: Ben Campbell , Barry Leiba , gendispatch@ietf.org, IETF discussion list , IESG Content-Type: multipart/alternative; boundary="000000000000d095900595b35f9e" Archived-At: Subject: Re: [Gendispatch] WG Review: General Area Dispatch (gendispatch) X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 03:02:08 -0000 --000000000000d095900595b35f9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Chiming in very late hear, but only to say something I hope is encouraging ... On Mon, Oct 14, 2019 at 7:19 AM Alissa Cooper wrote: > Hi Ben, > > > On Oct 11, 2019, at 3:12 PM, Ben Campbell wrote: > > > > > > > >> On Oct 11, 2019, at 4:10 AM, Alissa Cooper wrote: > >> > >> Hi Ben, > >> > >>> On Oct 10, 2019, at 6:05 PM, Ben Campbell wrote: > >>> > >>> Here=E2=80=99s an attempt to distill my concern a little better: > >>> > >>> The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thought of a= s a triage > process. Triage makes sense when you don=E2=80=99t have the time and reso= urces to > address every problem and have to pick and choose where you can have the > most impact. If you do have time and resources to address everything, the= n > triage is just a process bump. > >>> > >>> Do we believe that GEN area proposals will routinely exceed our > capacity to discuss them? If so, do we think that will continue to be tru= e > for the foreseeable future? (I assume this is intended to be a long-lived > wg). > >> > >> I guess I see the question differently. If there are people in the > community who are willing to manage discussions about process proposals > while they=E2=80=99re in formation (i.e., people willing to chair this WG= ), that > seems like a better arrangement than the current one both from the > perspective of being more community-led and from the perspective of the > other time commitments that the IESG has. If the WG isn=E2=80=99t busy or= meeting > all the time, that=E2=80=99s fine =E2=80=94 it will still be nice to have= it there for > times when process proposals do come up and inspire discussion. > > > > I think I=E2=80=99ve been unclear in my concern. I have no objection to= having a > working group for discussion of proposals to improve processes. I think > that=E2=80=99s a good idea. My question is about whether such working gro= up should > be limited to the dispatch process. > > > > Certainly there may be case where there it is appropriate dispatch work > to some other venue, spin up a new wg for a proposal, etc. But I wonder w= hy > we need to decide in advance that work on a proposal will cannot be > completed by this group. Especially when it seems likely that the people > working on a proposal will often be the same whether the work happens in > gendispatch or somewhere else. > > Ah, got it. This is a good question. Perhaps we can try it in > dispatch-style for awhile and see if we=E2=80=99re often arriving at an o= utcome > where it seems like just processing a document in the WG would be the mos= t > logical thing to do. If so, a re-charter to allow that would be possible.= I > was a little hesitant to jump straight to having a General Area Working > Group; the dispatch-style group seemed like it could be a useful > intermediate step. > I think trying something Dispatch-style will be helpful - it was helpful for then-RAI to have a way to sort through proposals without having to spin up full BOFs - and I'm reading Alissa's note here as "I want to try to do something that could improve things, and if we need to change what we're starting with in order to improve things, we can make changes, and keep trying to Do The Right Thing". That would be lovely. Best of luck! Spencer --000000000000d095900595b35f9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chiming in very late hear, but only to sa= y something I hope is encouraging ...

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 14, 2019 at 7:19 AM Alissa= Cooper <alissa@cooperw.in> = wrote:
Hi Ben,
> On Oct 11, 2019, at 3:12 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>
>
>> On Oct 11, 2019, at 4:10 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>>
>> Hi Ben,
>>
>>> On Oct 10, 2019, at 6:05 PM, Ben Campbell <ben@nostrum.com> wrote:
>>>
>>> Here=E2=80=99s an attempt to distill my concern a little bette= r:
>>>
>>> The =E2=80=9Cdispatch process=E2=80=9D can reasonably be thoug= ht of as a triage process. Triage makes sense when you don=E2=80=99t have t= he time and resources to address every problem and have to pick and choose = where you can have the most impact. If you do have time and resources to ad= dress everything, then triage is just a process bump.
>>>
>>> Do we believe that GEN area proposals will routinely exceed ou= r capacity to discuss them? If so, do we think that will continue to be tru= e for the foreseeable future? (I assume this is intended to be a long-lived= wg).
>>
>> I guess I see the question differently. If there are people in the= community who are willing to manage discussions about process proposals wh= ile they=E2=80=99re in formation (i.e., people willing to chair this WG), t= hat seems like a better arrangement than the current one both from the pers= pective of being more community-led and from the perspective of the other t= ime commitments that the IESG has. If the WG isn=E2=80=99t busy or meeting = all the time, that=E2=80=99s fine =E2=80=94 it will still be nice to have i= t there for times when process proposals do come up and inspire discussion.=
>
> I think I=E2=80=99ve been unclear in my concern. I have no objection t= o having a working group for discussion of proposals to improve processes. = I think that=E2=80=99s a good idea. My question is about whether such worki= ng group should be limited to the dispatch process.
>
> Certainly there may be case where there it is appropriate dispatch wor= k to some other venue, spin up a new wg for a proposal, etc. But I wonder w= hy we need to decide in advance that work on a proposal will cannot be comp= leted by this group. Especially when it seems likely that the people workin= g on a proposal will often be the same whether the work happens in gendispa= tch or somewhere else.

Ah, got it. This is a good question. Perhaps we can try it in dispatch-styl= e for awhile and see if we=E2=80=99re often arriving at an outcome where it= seems like just processing a document in the WG would be the most logical = thing to do. If so, a re-charter to allow that would be possible. I was a l= ittle hesitant to jump straight to having a General Area Working Group; the= dispatch-style group seemed like it could be a useful intermediate step.

I think trying something Dispatch-style = will be helpful - it was helpful for then-RAI to have a way to sort through= proposals without having to spin up full BOFs - and I'm reading Alissa= 's note here as "I want to try to do something that could improve = things, and if we need to change what we're starting with in order to i= mprove things, we can make changes, and keep trying to Do The Right Thing&q= uot;.=C2=A0

That would be lovely.=C2=A0
=
Best of luck!

Spencer=C2=A0
--000000000000d095900595b35f9e-- From nobody Fri Oct 25 14:16:08 2019 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E23120A20; Fri, 25 Oct 2019 14:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: alissa@cooperw.in, gendispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793059.2724.5060324585410622575.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:10 -0700 Archived-At: Subject: [Gendispatch] gendispatch - Requested session has been scheduled for IETF 106 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:20 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gendispatch Session 1 (1:00 requested) Monday, 18 November 2019, Afternoon Session III 1810-1910 Room Name: Canning size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/gendispatch.ics Request Information: --------------------------------------------------------- Working Group Name: General Area Dispatch Area Name: General Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 75 Conflicts to Avoid: Technology Overlap: artarea genarea cbor ace core lake quic dprive anima opsawg spring tls abcd wpack webtrans txauth tmrid raw mathmesh People who must be present: Pete Resnick Alissa Cooper Francesca Palombini Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 28 02:22:14 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C107120802; Mon, 28 Oct 2019 02:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 JDavj32gWOfw; Mon, 28 Oct 2019 02:22:06 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140058.outbound.protection.outlook.com [40.107.14.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E764A12021D; Mon, 28 Oct 2019 02:22:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QztkHmfoAb8nAD3MVElGEViMM0+lTF4HcwvjxhyN3zJFFThm8JZD68a8bDG5S/04EaFM2HvBcMab4i3JEhfM1q6jxit5XiVsncxpyxEn7a9TKd1/OsHXkJwJRiHnirzQeVvjx0PNgAS7L/piUWkeQQxLlmFf1XIYel2lkTB6WMKIHUOp1DaueS4xWVY7P0eiU4NQRsv9MiyvxpdWark89rUOil3nGcXXL8dHH/NY0NBJXkVLMBOhBNmspNUGdeAsjKzr/S80gl9VEvkyI6gg7pIEp0Zjp4XNxTKwPNKrdOkLEIsJarQguS4hQg6LC+KdH/DieLJ0bd0/bZ1FXsKDJA== 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=xA8PJH89uct+nZyIclIuLOZHCIrEa3/yLBjhPuPDY6Q=; b=WHzQ4Xs2mW8UtrPzckxQiGFD9JWJMhFDDzh1kCAZhyU6caulI3Hdn5stABlhJrrnG5MbPvKA0YVjFHzELMGqxbTEE6jeqBq2r7zGwb8aOzCrXLmcatVPjpoV/vi06aFxG82AZXjxPtAc6olv8RTZQQqkIu3INEkKblk9fhE8S43Z6aohuccggo+Yiyi8gvpH1wf1Ah/umNs8LTsNiwMmEz0tv/TFjP6QXnqYGQiuU++kr6YdmPciakUjS0TJCbxMyeKwpcrsadgF56WYxF5mA5PGbH9N+8z3AY7qCcklTCYPptxhSMA6/7xTm6w47Uwzo1UEaX8TZ0VaUy4ji1tUnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xA8PJH89uct+nZyIclIuLOZHCIrEa3/yLBjhPuPDY6Q=; b=RT14vziSI+6ZeXRWUy0raOuhdFDATfbVaWWOCbiDWbeWKvMDdcDg1IxaOrf/QsbBTbMHKtyjGreEENSWPfSGEl/LBRdDbqG8qbqZPVP2BeJD0hsbnaTt0fRJaJFqNtYmHBhmhgIFJZsULhlm3k6F7U7RuQoNkWQ2I48R7wbin2A= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2841.eurprd07.prod.outlook.com (10.168.94.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.15; Mon, 28 Oct 2019 09:22:03 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::e44f:9e37:923e:1580]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::e44f:9e37:923e:1580%9]) with mapi id 15.20.2408.014; Mon, 28 Oct 2019 09:22:03 +0000 From: Francesca Palombini To: "gendispatch@ietf.org" CC: "gendispatch-chairs@ietf.org" Thread-Topic: Agenda call for items IETF106 Thread-Index: AQHVjXEoMC8hpLAYS0KegCM1hwsppQ== Date: Mon, 28 Oct 2019 09:22:02 +0000 Message-ID: <4C9B6C4E-D686-4764-8C8E-10BE5E2A3284@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01c891a2-9c05-480c-6e8b-08d75b884b29 x-ms-traffictypediagnostic: HE1PR0701MB2841: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(53754006)(189003)(199004)(102836004)(4326008)(81166006)(7736002)(6506007)(66066001)(186003)(486006)(33656002)(8936002)(26005)(6436002)(6486002)(25786009)(36756003)(44832011)(99286004)(256004)(6306002)(6512007)(71200400001)(71190400001)(1730700003)(81156014)(450100002)(2906002)(8676002)(5640700003)(476003)(2616005)(478600001)(2501003)(966005)(86362001)(5660300002)(14444005)(66556008)(66476007)(76116006)(64756008)(66446008)(316002)(2351001)(6916009)(3846002)(14454004)(305945005)(6116002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2841; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a9EA14MgF53AFf7UFrxRoqG0hKr+1htg+kknqEzLHvxZ/DnXPiaSaLapMaTXr/0PcKFeFdpMXJwU5l/+RWFpMM6KtHAHLFLosRehZqOZDGfTUYlMtLM251/e0tWu0O5BSxqe094d2kjh8S+8StK5mK4ne4KojFd7zXzCAgqp8IhfHD0m0BCIX0sVPMNiHeOI5ZksDqX0/K+XS7NJ0dPXEt0Z33xm4VqyqdvPa6FRiHHCR9DFZ4tuh6nesUHu7cssy9VW0wAo4AdK5yyWF15MBD2bm7V3AHn8vaOoG7oRU8r0H5942N2s3tanYHhT+3E7AayTlgp+JeTZ9csQAhbwXXBIWteJ3UKT6zJBuyg4Ud0pV06S91kH373cND9enYb4XAtOKkvEtwtCwQBwby+KwjJpxKXVX4mdDktYOC0ZDCDyqwUpxX6fuEFxJfXcsCs3XHAOmsGkD/ewdYGERIyzrbexvVUoVhkEb38xchYpkwI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01c891a2-9c05-480c-6e8b-08d75b884b29 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2019 09:22:02.9481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NhIEJyZNyysj+w9uNJ22aYylO3j4r3spP2XkIJd/NXxU09YPmG/CVqA4kJhk/IzrTatICDIHc+fQRvJPRk0kB3xSgnz+MeqTooQIixm5tnr2M6oi6zXuzCS5iFA5jsNP X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2841 Archived-At: Subject: [Gendispatch] Agenda call for items IETF106 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 09:22:13 -0000 SGkgYWxsLA0KDQpXZSBhcmUgc3RhcnRpbmcgdG8gcGxhbiB0aGUgZ2VuZGlzcGF0Y2ggc2Vzc2lv biBmb3IgSUVURjEwNi4gSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGhhdmluZyBhIHByZXNlbnRh dGlvbiBzbG90LCBwbGVhc2Ugc2VuZCBhIHJlcXVlc3QgdG8gdGhlIGNoYWlycyBieSBUdWVzZGF5 IE5vdiA1dGgsIHdpdGggdGhlIGZvbGxvd2luZyBkZXRhaWxzOg0KDQotIERyYWZ0DQotIEFic3Ry YWN0DQotIFRpbWUNCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDI1LzEwLzIwMTksIDIz OjE0LCAiR2VuZGlzcGF0Y2ggb24gYmVoYWxmIG9mICJJRVRGIFNlY3JldGFyaWF0IiIgPGdlbmRp c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFnZW5kYUBpZXRmLm9yZz4gd3Jv dGU6DQoNCiAgICBEZWFyIEFteSBWZXp6YSwNCiAgICANCiAgICBUaGUgc2Vzc2lvbihzKSB0aGF0 IHlvdSBoYXZlIHJlcXVlc3RlZCBoYXZlIGJlZW4gc2NoZWR1bGVkLg0KICAgIEJlbG93IGlzIHRo ZSBzY2hlZHVsZWQgc2Vzc2lvbiBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieQ0KICAgIHRoZSBvcmln aW5hbCByZXF1ZXN0LiANCiAgICANCiAgICANCiAgICAgICAgZ2VuZGlzcGF0Y2ggU2Vzc2lvbiAx ICgxOjAwIHJlcXVlc3RlZCkNCiAgICAgICAgTW9uZGF5LCAxOCBOb3ZlbWJlciAyMDE5LCBBZnRl cm5vb24gU2Vzc2lvbiBJSUkgMTgxMC0xOTEwDQogICAgICAgIFJvb20gTmFtZTogQ2FubmluZyBz aXplOiAyNTANCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgDQogICAgDQogICAgaUNhbGVuZGFyOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvMTA2L3Nlc3Npb25zL2dlbmRpc3BhdGNoLmljcw0KICAgIA0KICAgIFJl cXVlc3QgSW5mb3JtYXRpb246DQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgV29ya2luZyBHcm91cCBO YW1lOiBHZW5lcmFsIEFyZWEgRGlzcGF0Y2gNCiAgICBBcmVhIE5hbWU6IEdlbmVyYWwgQXJlYQ0K ICAgIFNlc3Npb24gUmVxdWVzdGVyOiBBbXkgVmV6emENCiAgICANCiAgICBOdW1iZXIgb2YgU2Vz c2lvbnM6IDENCiAgICBMZW5ndGggb2YgU2Vzc2lvbihzKTogIDEgSG91cg0KICAgIE51bWJlciBv ZiBBdHRlbmRlZXM6IDc1DQogICAgQ29uZmxpY3RzIHRvIEF2b2lkOiANCiAgICANCiAgICAgVGVj aG5vbG9neSBPdmVybGFwOiBhcnRhcmVhIGdlbmFyZWEgY2JvciBhY2UgY29yZSBsYWtlIHF1aWMg ZHByaXZlIGFuaW1hIG9wc2F3ZyBzcHJpbmcgdGxzIGFiY2Qgd3BhY2sgd2VidHJhbnMgdHhhdXRo IHRtcmlkIHJhdyBtYXRobWVzaA0KICAgIA0KICAgIA0KICAgIA0KICAgIFBlb3BsZSB3aG8gbXVz dCBiZSBwcmVzZW50Og0KICAgICAgUGV0ZSBSZXNuaWNrDQogICAgICBBbGlzc2EgQ29vcGVyDQog ICAgICBGcmFuY2VzY2EgUGFsb21iaW5pDQogICAgDQogICAgUmVzb3VyY2VzIFJlcXVlc3RlZDoN CiAgICANCiAgICBTcGVjaWFsIFJlcXVlc3RzOg0KICAgICAgDQogICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgLS0g DQogICAgR2VuZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQogICAgR2VuZGlzcGF0Y2hAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlbmRpc3BhdGNoDQog ICAgDQoNCg== From nobody Thu Oct 31 16:37:01 2019 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CED1200B9 for ; Thu, 31 Oct 2019 16:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rlTl4BdZ4NFs for ; Thu, 31 Oct 2019 16:36:58 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 9169312004F for ; Thu, 31 Oct 2019 16:36:58 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id t10so3461666plr.8 for ; Thu, 31 Oct 2019 16:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ljqgjY7u75VIuXG1WhAPdyP+VoNAh2JCQftufo6hN0o=; b=lFqVHNtzdrhvUPOMPTa1oPNsQypMR5q3JHcPiWV9THPt8GOJgj5uaNPkpoEV6yMiej VAgRAuMD3KtL1+ifkdhVTZCmBTO6V6QZKbPSjwqVqwymaNPD28rN7tKOZf5Ec3Z1qBYS YYMwUbIKEAGkT4A/VHP8OTgCpLTctIjrbbX2LLppQoHchBWQjeK2+1jOtXwxR8wQZiOk otjdJSQR3MGR36MR4t4Wk0RkQgQ/tv3tE+jr/BQCjxdKHqohZKY/DoBDRCH/tiaNPZpg DUeS12sBQdtjOnuIokw8+42NLxpyF/xMXzsTHl70nr6Y1XuvUVne2BgSTdeo2P9cuekl KDfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ljqgjY7u75VIuXG1WhAPdyP+VoNAh2JCQftufo6hN0o=; b=g9APUTxLb2TyzMfTjAeaQgQAq9/qZKh16zqUnRPlfDh+pbmThYQk7De1YnuFdxtXXu n5cSjVpwH1SPFfIdIvoTnrI/MWkA0oEFOdDP6/Xw6PYlpRnem2FT6KfO6N2kWb5/CPPE lGOqRPaouFFZSvI2J2RL6hrB0gmpOR7dnfNqh6lRXaNCfhCrFb6BRYefx3DKpwmGoE+W neAb47FlYENoKcCDCFxvHnsUzpL/15OLz7ZJWy7GoOcS2QfRUFJZwyD7ROffahmsGNPI oO5r5EdmYdxZ6sv/y+TYwqLmB0F0X+RGFJfjvegTawC5Yt/Q+5L4qDO394zPDTZwZcW9 ddiA== X-Gm-Message-State: APjAAAUq88ypu5MkjlshnDP+ByTXSS2YyVqkp7YcYZv91Z6tMcTmv1jB NlpT+HMhia2HuG3voFzdD8bYF+yq X-Google-Smtp-Source: APXvYqy8k8XSC6P+DHjXBfw73Bmq8jC2q8+QGBAy5n4wlhV8o/SGeqpq/TYGefCcPaXBBFsNIxmXaw== X-Received: by 2002:a17:902:9696:: with SMTP id n22mr8633607plp.252.1572565017651; Thu, 31 Oct 2019 16:36:57 -0700 (PDT) Received: from [192.168.178.30] (46.137.69.111.dynamic.snap.net.nz. [111.69.137.46]) by smtp.gmail.com with ESMTPSA id v1sm6959990pjd.22.2019.10.31.16.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Oct 2019 16:36:56 -0700 (PDT) From: Brian E Carpenter To: Francesca Palombini Cc: gendispatch@ietf.org References: <0BD8D4BC-26C0-44B1-848C-46B2BF8EAEC6@ericsson.com> Message-ID: <1806bafe-18ce-718a-b73c-bac6e8befc44@gmail.com> Date: Fri, 1 Nov 2019 12:36:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <0BD8D4BC-26C0-44B1-848C-46B2BF8EAEC6@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] Gendispatch agenda call for items IETF106 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 23:37:00 -0000 Can I suggest a generic agenda item? It seems to me that gendispatch could usefully build a simple list of potential process issues in need of attention. A list in the WG wiki would be fine - a one line description of each item and the names of people interested. This wouldn't be a commitment to do work; it would just serve as a shopping list and a way to signal interest. If people agree, there's no need for meeting time at all. Just do it. Regards Brian Carpenter On 31-Oct-19 21:28, Francesca Palombini wrote: > > Hi all, > > We are starting to plan the gendispatch session for IETF106. If you are interested in having a presentation slot, please send a request to the chairs by Tuesday Nov 5th, with the following details: > > - Draft > - Abstract > - Time > > Thanks, > Francesca > > On 25/10/2019, 23:14, "Gendispatch on behalf of "IETF Secretariat"" wrote: > > Dear Amy Vezza, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > gendispatch Session 1 (1:00 requested) > Monday, 18 November 2019, Afternoon Session III 1810-1910 > Room Name: Canning size: 250 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/106/sessions/gendispatch.ics > > Request Information: > > > --------------------------------------------------------- > Working Group Name: General Area Dispatch > Area Name: General Area > Session Requester: Amy Vezza > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 75 > Conflicts to Avoid: > > Technology Overlap: artarea genarea cbor ace core lake quic dprive anima opsawg spring tls abcd wpack webtrans txauth tmrid raw mathmesh > > > > People who must be present: > Pete Resnick > Alissa Cooper > Francesca Palombini > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > > > >