Re: [OAUTH-WG] Structured management of working documents

Benjamin Kaduk <kaduk@mit.edu> Sun, 26 April 2020 21:31 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AB83A12BD for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 14:31:17 -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 395dwH4pZn0S for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 14:31:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6B1A83A12BC for <oauth@ietf.org>; Sun, 26 Apr 2020 14:31:15 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03QLVA9N013379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 17:31:13 -0400
Date: Sun, 26 Apr 2020 14:31:10 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jared Jennings <jaredljennings@gmail.com>
Cc: oauth <oauth@ietf.org>
Message-ID: <20200426213110.GQ27494@kduck.mit.edu>
References: <CAMVRk+LbUcb0=_MYfK_HicfqsoxTx_=eeOeH8zuBr4WJ1zS5Ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMVRk+LbUcb0=_MYfK_HicfqsoxTx_=eeOeH8zuBr4WJ1zS5Ow@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/a76MZd183aJ_6MHvUPMtO60eG34>
Subject: Re: [OAUTH-WG] Structured management of working documents
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 21:31:18 -0000

Hi Jared,

On Thu, Apr 23, 2020 at 09:55:21PM -0500, Jared Jennings wrote:
> Hi all,
> 
> I know I am super new to the list, so bare with me with my
> observations that I would like share with the group. Probably no one in the
> list knows me, but I am used to online forms, mailing lists and I been
> involved in various open source applications for many years. So, these
> comments do not come from someone that isn't used to mailing lists.

Thanks for being bold and sharing your insight!  It is not often that we
have the benefit of such a fresh perspective.

> With that said, I find it difficult to follow the different
> threads, revisions, suggestions, comments, and topics that we discuss. It
> also seems that the current format makes it very difficult for the
> maintainer of the document.
> 
> As a suggestions or question, is there a reason we are not using a platform
> designed for this type of work? Like Github, bitbucket, etc. A great

The main reason that we continue to involve the IETF mailing list is due to
a longstanding historical IETF requirement for having WG work gain
consensus on the mailing list and be submitted to the IETF datatracker.
The original reasons for this policy (which long predates me, to be clear)
seem twofold: to be as accessible as possible to all (email does not
require significant bandwidth, real-time access, or installing/using
proprietary software), and to ensure compliance with the IETF IPR regimen.
With respect to the latter point, the IETF mailing lists and
datatracker-managed documents are subject to the "Note Well" policies of
BCPs 78 and 79, and the procedures for making other tools subject to the
same requirements are less well-established.

> example is the link that Brian shared. I can see exactly what is going on
> and I could even propose my own patch, which saves the editor loads of work.
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/3/attempt-to-tweak-the-wording-in-jar-so/diff

The above notwithstanding, the IETF has recently approved a pair of
documents that describe procedures for how a WG can choose to use github in
the course of their work.  (They are not RFCs yet, but are with the RFC
Editor in preparation as RFCs; they're linked from
https://datatracker.ietf.org/wg/git/documents/ .)  These procedures focus
on github because it's popular, but aren't intended to limit WGs to just
github as an available external tool; the procedures in question could no
doubt be modified to apply to other tools as well, if there is WG consensus
to do so.

Hope this helps,

Ben