Re: [Rfced-future] Issue 144

John C Klensin <john-ietf@jck.com> Thu, 06 January 2022 01:44 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355983A134D for <rfced-future@ietfa.amsl.com>; Wed, 5 Jan 2022 17:44:40 -0800 (PST)
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 WkHs9bOQw2gz for <rfced-future@ietfa.amsl.com>; Wed, 5 Jan 2022 17:44:35 -0800 (PST)
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 72ECA3A134C for <rfced-future@iab.org>; Wed, 5 Jan 2022 17:44:33 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1n5HpO-000CPd-6K; Wed, 05 Jan 2022 20:44:30 -0500
Date: Wed, 05 Jan 2022 20:44:23 -0500
From: John C Klensin <john-ietf@jck.com>
To: Scott Bradner <sob@sobco.com>, Peter Saint-Andre <stpeter@stpeter.im>
cc: rfced-future@iab.org
Message-ID: <39A3792DA76E797670E06BA0@PSB>
In-Reply-To: <8C799458-F53B-45F1-8AF1-278BE5E5B1C1@sobco.com>
References: <CABcZeBO3-q+SMTFNZyeC50eghFs1CJNSLojmr1Zip1g_nsGZHQ@mail.gmail.com> <d7ce7879-2324-69d1-0770-e104aff6c68c@stpeter.im> <53497e97-ed65-93c8-5f4c-3f4ee9943501@stpeter.im> <abb0c140-2bed-312b-4f25-c36bee0c1f56@gmail.com> <db4d809d-a64e-4350-ecb4-5e85dca8ba40@stpeter.im> <8C799458-F53B-45F1-8AF1-278BE5E5B1C1@sobco.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: <https://mailarchive.ietf.org/arch/msg/rfced-future/4BSL2H9cX2jGTp8AKRAsRcrVV4w>
Subject: Re: [Rfced-future] Issue 144
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jan 2022 01:44:40 -0000


--On Wednesday, January 5, 2022 19:43 -0500 Scott Bradner
<sob@sobco.com> wrote:

>  Peter Saint-Andre <stpeter@stpeter.im> wrote:
> However, I don't see exactly where it talks about advance
> notification for "other working group meetings". I must be
> missing something obvious.
> 
> 7.1. Session documents
> 
>    All relevant documents to be discussed at a session should
> be    published and available as Internet-Drafts at least two
> weeks before    a session starts.  Any document which does not
> meet this publication    deadline can only be discussed in a
> working group session with the    specific approval of the
> working group chair(s).  Since it is    important that working
> group members have adequate time to review all    documents,
> granting such an exception should only be done under
> unusual conditions.  The final session agenda should be posted
> to the    working group mailing list at least two weeks before
> the session and    sent at that time to agenda@ietf.org for
> publication on the IETF web    site.

Of course, in addition to whatever properties it might have as a
model of clarity, the rules of that section may be a rather good
candidate for the set of IETF procedural requirements that are
most often completely ignored, and ignored without any
consequences.  :-(.  In particular, if this group were required
to follow IETF WG rules, IIR that document availability rule has
been violated more than once.

In any event, the RSWG is _not_ an IETF working group, so it is
not clear how applicable RFC 2418 is.   In particular, a decent
protocol or procedure lawyer could easily claim that anything
the RSWG does is "consistent with RFC 2418". Because 2418 says
nothing about non-IETF WGs, anything such a body is consistent
with its specifications.   Add to that the observation that, if
we are lucky, 2418bis might actually be approved reasonably
early in the RSWG's life, requiring that provisions of this
document and the normative reference be noticed and updated, and
I'd argue for making this provision self-contained.  That might
be just Peter's text at the beginning of this thread plus

* A statement about how far in advance any relevant documents
are supposed to be available.

* A statement that notification should be to all of the lists
used by the RSAB/RSWG for other purposes.  That list should
either be enumerated in the document or, better, the RSAB
charged with maintaining such a list and keeping it publicly
available.

  john