Re: [Gendispatch] GENAREA @ IETF 118

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 October 2023 03:49 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 D1ED3C14CE52 for <gendispatch@ietfa.amsl.com>; Wed, 18 Oct 2023 20:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.197
X-Spam-Level:
X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghXDnNa-kQYy for <gendispatch@ietfa.amsl.com>; Wed, 18 Oct 2023 20:49:54 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0558C14CF1B for <gendispatch@ietf.org>; Wed, 18 Oct 2023 20:49:54 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-6c4b9e09521so4924163a34.3 for <gendispatch@ietf.org>; Wed, 18 Oct 2023 20:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697687394; x=1698292194; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PtcfBVMlUVVAJVUvHIj6FIxhZ5QLG4hApd8G39jlTdU=; b=Xn9brzhhhmB/KCXXulZ1Cl1vfo4ZbvzYIz2ONROB3CqrX2Q9w+rzc9kLZtSCB8pojY YPuJORQvB3aoCRSMJgBa+GYTLnAnWgenb15l/y5KyjlIO0Yf9l+HU3weJvmGZUjbAM5M VkGsztnibXicV/bXfbmDm0KbTkSgoNTuJ+iT09XrsszsQFoM/s4sbrO4+9fIS0fgHghe hmqDcEnjrWu8P7Sih7xu+kUa/xXODEsbjftlSdNFVBZEgjDayv+ddBpvqzKxvy6h3Zu9 ruKH4N5ZXhC8NuuPGFRA0DF6ozIuniPj5rvZN6vM8vnwFRFS5xwFezqQMOJcTa2BZq/X ZZKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697687394; x=1698292194; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PtcfBVMlUVVAJVUvHIj6FIxhZ5QLG4hApd8G39jlTdU=; b=Y8AKhQ64w1g5STnX+Wgk2sqTeIuEA5M6h4+HwW87TQP2+pOI9ym+l8i+MpYe5qSqfn S8aZ9Od0RKBsbfSRE7ofyf4IUVqJAnQSlk3Mb9gLpwtr0xVES1rWk6q6TxdLcH4hGhxZ KfT1UUw1QSfauc/qfAP3pWrQgVc/hNPdGWMulmBuOp2lkYBNGS2TePYmQW+Qk/Jd8Qv3 tmNxWklYPKuMZ7dNLf+QORnJempIs6Zp6lpy38GFD+5ZfnIwD9phT5fbOEvMz4oUgfPx mtkxPGzpvzoyeMxQEiTnwBiYVQjKqE8Y7ViC5t80buRUlTN7lCjXzjvM61bfWRsRF7tZ 7sDw==
X-Gm-Message-State: AOJu0YyBYFXjF4SPBj96sy8SpycQFxLaRjtlBNATl/MZbqJ4R9TfRSSt xlsmgkS1GsfAMo4GV0Qke2WPzVtcosK4+Q==
X-Google-Smtp-Source: AGHT+IH9nopSfyd5DKsyPTp2S91GrKM5vYTyaKgEyJQs5x6UL+r0auMVbD1TNML1iqwkcoJi2OOtdA==
X-Received: by 2002:a05:6830:601:b0:6b9:9288:613c with SMTP id w1-20020a056830060100b006b99288613cmr1283886oti.13.1697687393822; Wed, 18 Oct 2023 20:49:53 -0700 (PDT)
Received: from ?IPV6:2406:e003:110d:5301:8cb6:a2c:7461:4047? ([2406:e003:110d:5301:8cb6:a2c:7461:4047]) by smtp.gmail.com with ESMTPSA id t26-20020aa7947a000000b006933e71956dsm4094305pfq.9.2023.10.18.20.49.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Oct 2023 20:49:53 -0700 (PDT)
Message-ID: <ddcf378f-2dab-31a2-3640-6da2930bf1dd@gmail.com>
Date: Thu, 19 Oct 2023 16:49:50 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Mark Nottingham <mnot@mnot.net>
Cc: "gendispatch@ietf.org" <gendispatch@ietf.org>
References: <34198747-EA5F-4B24-BDF0-43A93D5416E2@eggert.org> <d9171030-5d69-3733-ff95-e40771ff4b64@gmail.com> <1818676D-8004-46B0-89C8-ACFEDE12556F@mnot.net> <64db83e6-7255-384c-e1b8-fb15c41c5735@gmail.com> <F431028C-2896-4B3C-AA95-99C715E2C17E@mnot.net> <84d540d6-5190-9854-89a4-55f356eae082@gmail.com> <BY5PR11MB4196C330CB04CE013AF4C6EEB5D5A@BY5PR11MB4196.namprd11.prod.outlook.com> <926D2201-8A8D-4202-ABB8-2C9161154494@ietf.org> <a430c2af-6719-43ff-a0a4-5a07de2f9bb0@lear.ch> <3c535b9b-b725-4d95-1f88-32f91d8a62d6@gmail.com> <B9CF9741-2146-4E4C-A70D-9800D1549324@mnot.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <B9CF9741-2146-4E4C-A70D-9800D1549324@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/RPV9xr3_bZw_TtDATyqOu3xwxHw>
Subject: Re: [Gendispatch] GENAREA @ IETF 118
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2023 03:49:58 -0000

On 19-Oct-23 15:36, Mark Nottingham wrote:
> 
>> On 19 Oct 2023, at 9:00 am, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> That said, on the original topic, I think Rob Wilton has hit the nail
>> on the head. So the Gendispatch question is whether there'd be support
>> for a proposal to completely rejig our process documents in that way?
> 
> No, that's a red herring, not the 'original topic'. My interest and my proposal are not in getting an RFC published for the sake of it; let's not be distracted by those concerns.

Well, I don't think that the question of how we control our mess of process documents is a red herring, because it means we are walking in thick mud every time we try to change processes and procedures, but on your point:

> 
> What I *am* proposing is that we need the DISCUSS criteria to be more under community control. Let's compare.
> 
> The current criteria were developed by the IESG. They decided when to do so, 

I don't want this to appear all defensive, but https://datatracker.ietf.org/doc/draft-iesg-discuss-criteria/ was exposed to the community and was discussed on ietf@ietf.org in 2005 and 2006. The first request for community comments went out in July 2005**. There were certainly  modifications as a result, but there was no formal Last Call since it wasn't turned into an RFC.

** https://mailarchive.ietf.org/arch/msg/ietf/ja_KrarzgEgbEKOqdUE0E1OiXnY/

> and when to update them subsequently. 

I have no information about subsequent updates.

> They oversaw the process of development, and were the final judge of the outcome. Their discussions about it and the considerations they took into account were effectively private to the IESG. If someone doesn't like the DISPATCH process itself (rather than its outcome), there is no effective avenue for appeal, arguably.
> 
> In contrast, if the DISCUSS criteria were approved by a WG-like process (no matter where they ended up), that would be overseen by a Chair who had a mandate to be independent and unbiased; discussion would be open and on the record; any member of the community could make a suggestion that would be considered by the entire community (or at least, those interested), and an update could be instigated if there were sufficient support within the community. Presumably, the IESG would approve the final output still, but be subject to appeal if they overstep.

For something like this to work, it really needs to be a genuine dialogue between the IESG and the interested subset of the community. Or to say that a bit differently, the IESG needs to be actively engaged in the discussion. I do very much agree that community involvement is necessary. I thought that in 2005 and I still do.

    Brian

> 
> There are, of course, other approaches to this; however a WG-like process is one that we're all familiar with, and we've had some success with RSWG. The extent and lifetime of such a body is open for discussion; I'd be happy if it did this one thing and shut down until a revision is necessary.
> 
> That's what I talked about at GENDISPATCH in San Francisco, with considerable support in the room IMO. It's what I'd like to talk about at GENAREA in Prague.
> 
> Now, of course, we need to figure out how to reflect that community consensus -- an RFC is an obvious choice, but if you really want to reflect it in a policy document on the Web site, so be it.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
>