IETF Logo Mail Archive

Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 March 2022 19:22 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 50F8A3A0980 for <rfced-future@ietfa.amsl.com>; Wed, 2 Mar 2022 11:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 6iT5f2wK41Ek for <rfced-future@ietfa.amsl.com>; Wed, 2 Mar 2022 11:22:31 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C4F3A098C for <rfced-future@iab.org>; Wed, 2 Mar 2022 11:22:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C765D38BC0; Wed, 2 Mar 2022 14:31:29 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hs3vrFqLxx5s; Wed, 2 Mar 2022 14:31:28 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 65AEE38BB4; Wed, 2 Mar 2022 14:31:28 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1646249488; bh=fjeJSXovvMCPLAnLJzE7VxuHTMwZqUazAtuj1XjJbXY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=NxOWubHpRbh0q5gyMj9sSfdEN0hvTcZhJdgeRrpVYgCgcmtHYwRrXGTWbt8/fTSdS +Fm1qenUy7O1mL9VKoGYey7LgM4xM/qHkxIwlaqW4HJyVC3muicL4CMIni52phGYir jI63fHtSePAXjpOWFGBuPEg1CBRgsR+Zr5pd/gt/IoP7QhQzWb1I49qWK2OjXNvQwF a5I3+8DKLUbFKlurSA0c1KL0WQuumlJIyew6OIwGORd4QY/bS1tGYL9N29m2Mpohg6 +ifyZB6NOPaSrSsXDYBfNo90Ae0TR/e+hNqpj+1+++2nCY6gG+sKH2W2HK3B7cIAnP 6nGbJQ0Ux6GFg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5E8FC2B3; Wed, 2 Mar 2022 14:22:27 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Lars Eggert <lars@eggert.org>, rfced-future@iab.org, RFC Interest <rfc-interest@rfc-editor.org>
In-Reply-To: <BEB26FE0-CC24-4EC2-B7E5-6556A2425A24@eggert.org>
References: <164574145917.13799.12710132950530774405@ietfa.amsl.com> <CA+9kkMC+vkyMPbt755Bu0cZHfmY-Pz6CdU1-J+8sBa8cPkA0dg@mail.gmail.c om> <CABcZeBMeRFOU+az=b8QJmD+-4GHivwZenMHEXsrbnamuoEmwEA@mail.gmail.com> <CA+9kkMAg_xbTODu=UE288uxTVhL=+r18p5ywC6ZGaUvpyXO8bA@mail.gmail.c om> <7C442BD6-F634-4129-9764-1BE29382D629@att.com> <8129A65C40CD88E0B5C94AA8@PSB> <7BC3F808-434B-48CF-B96B-0CF7D8B9F3A7@tzi.org> <EEF0F457622EDF74E090BC66@PSB> <BEB26FE0-CC24-4EC2-B7E5-6556A2425A24@eggert.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 02 Mar 2022 14:22:27 -0500
Message-ID: <11721.1646248947@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/VDvDICiYB_hrningtseMNspBS-4>
Subject: Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)
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: Wed, 02 Mar 2022 19:22:37 -0000

Lars Eggert <lars@eggert.org> wrote:
    > I thought about this a bit, and it's not immediately obvious to me that
    > procedures for AUTH48 handling are under the purview of the RSWG.

I don't mind if AUTH48 options are under the purview of the RSWG.
That might require that we ask the RSWG to amend itself, and I'm okay with that.

    > could see an argument being made that they are under the purview of the
    > individual streams. There are already minor differences between the
    > streams, for example, the IRSG is in the loop for AUTH48 exchanges or
    > the IRTF stream, but the IESG is not for the IETF stream.

It seems that there are a few boolean options that different streams might
want to turn on off, and at the least, we should say what they are.
In the end, it might be that things are the way they are because the
different stream managers were ignorant of the options.

    > It's true that so far, all streams have used - more or less, see above
    > - the same process for handling AUTH48 processing. If that is intended
    > to be one of the invariants of the RFC series, I agree that any changes
    > would be under the purview of the RSWG, and any changes would then also
    > apply to all streams.

I would prefer that AUTH48 process didn't varry much, or at all.

    > But I could also see a future where one stream would want to revise how
    > AUTH48 should be handled for their documents. If this is something we
    > would like to allow - and personally (with no hats) I think that could
    > be attractive - then I don't see how this could be under the purview of
    > the RSWG, given that they are setting policies for the series (but not
    > the individual streams).

I guess the only reason I think that we should allow variances is so that
smaller groups can try something new, innovate, and then report their
results.   It otherwise seems like change for change's sake to me.




--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email