Re: [Tsv-art] [Ietf-and-github] Tsvart last call review of draft-ietf-git-using-github-04

Martin Thomson <> Wed, 04 March 2020 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36E6B3A0CA9; Tue, 3 Mar 2020 19:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=AOjxo8/S; dkim=pass (2048-bit key) header.b=CuTDBOyI
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XxZS9gALVC-o; Tue, 3 Mar 2020 19:20:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FDFA3A0CA7; Tue, 3 Mar 2020 19:20:35 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 41FA022299; Tue, 3 Mar 2020 22:20:34 -0500 (EST)
Received: from imap2 ([]) by compute2.internal (MEProxy); Tue, 03 Mar 2020 22:20:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=hmZxz9oLi8kztuW5idlmKrmS1M1M ZHqzY9I2q7LGnF8=; b=AOjxo8/SuNYf9lK2rdc6PAd8rawkmh+mZFQoZkq2X3At Du+nTMnZNLUxHU6WNZsXAqJngKJ/wOkRJGJpYUForHd3UJTvZru9rOn65B4Pc8ZH HcWYmrkhWpRe5VGAa11j2SXzqfT74SmQ2oOPv/hN8ZNZSDK3Cu9pxq/jTGjKubei gXnt9vSXlwkULE4wWj9810TGhqJp7/FvF/08prybRpZpFJ2uZ3wHoGdubPn5Trjx LBJZi6QXONquEli7atBoBgQBZuzcXkuJwKgI+2Zqv7UM3tfJOppDfmq5zWqaw6c6 jk9lX9hRdzi8C8pNaohr3kV/CoP40yKI4Re6t2Aiog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=fm2; bh=hmZxz9 oLi8kztuW5idlmKrmS1M1MZHqzY9I2q7LGnF8=; b=CuTDBOyIZLKU6q9oWTbXCv d3jRzJEI1U3NVFZSXTMJdKJo+f8EdW3OZ0l0M1P7gy/PkPVwDMSTbwB6yR5+lcl4 sVwUVTP7HKt1iPOJKLSQdkn7NpmSbaJ/z63KFjIJZNRFA3QU8h6tCHaLTgjoplur iJ26mZdVRz4E7uIxDetXQ6AaxOoLv0IEZTGmy88bczqRsP5A2OY8qWhlXYnbSJuu eAMANCTRPOh1w/WpDv0v4NG21geXI7X1m6WJNcwPnLz4AYCKQ9Xg1KdtorkQQNIR o/PcFJmcbahmniTKE+t+pmEdT/hX6lS13Q9lZtq5CjS3amawbs229UwATOYF6grw ==
X-ME-Sender: <xms:gR5fXv5Z4gMTMbagWx3C3Ulrup6MT4LHSRpA1kTdsa-sZu2BuB7mxg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtjedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:gR5fXo2uy-MDjWuwA__WDnNpOYMXNyCBEehibleEx1yL9lnvF1I8dg> <xmx:gR5fXvj-umuTpg9UUWEtAvXoPjUFfLMfvdOSfiMHv2fBTAqTXIfK7w> <xmx:gR5fXorn97Q9iPYzGWwawbxCvs8W7CAomqko8y-GMsV8Y5atZIZZFA> <xmx:gh5fXjU0wpL9ewKnG3a6qEGVF0wzBACvdfkiaggdBTpxuTm-M4fZ6A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9211FE00D7; Tue, 3 Mar 2020 22:20:33 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-986-gfc2d493-fmstable-20200304v3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 04 Mar 2020 14:20:15 +1100
From: "Martin Thomson" <>
To: "David Black" <>,
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Tsv-art] =?utf-8?q?=5BIetf-and-github=5D_Tsvart_last_call_revie?= =?utf-8?q?w_of_draft-ietf-git-using-github-04?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2020 03:20:38 -0000

Hi David,

Thanks for the review (and apologies for having it slip the net until now).

On Sat, Feb 29, 2020, at 12:25, David Black via Datatracker wrote:
> [1] The split of Issue Tracker material across Sections 4.1 and 5 seems off.
> In particular, Sections 4.1.2 and 4.1.3 on closing and reopening issues are
> strongly connected to the Section 5 discussion of WG policies for Issue
> Tracker usage and hence ought to be moved into Section 5.   The Section
> 4.1 discussion on use of labels could likewise benefit from being merged
> into the more extensive discussion of WG use of labels in Section  5.4 .

This is a hard one.  The advice in Section 4 is intended to be generic, whereas Section 5 is intended to narrow this to the point of being specific.  That naturally produces duplication, but I'm not seeing anything in Section 4.1 that is not universally applicable.
> [2] The example WG policies in Section 5 come tantalizingly close to being
> well known policies that can be used by reference in a fashion analogous to
> the well-known IANA registry management policies in Section 4.1 of
> RFC 5226 (   Doing the
> analogous thing with these GitHub policies is likely to be greatly appreciated
> by WG Chairs who are new to WG use of GitHub.  However, use of GitHub
> may not have matured to the point where this is a sensible thing to do, and
> hence I leave the determination of whether this should be done to the
> authors' and the IESG's best judgement.

The 8126 categories have become more precise over time in a way that has allowed us to use labels, but the need there is more acute.  To me, the titles of Section 5.1 and 5.2 might be used with a fair degree of confidence in their meaning, but Section 5.3 is still a more nebulous.  My sense is that these will ultimately be the labels that end up being used, but their definitions are still quite loose.  Letting this tighten up as we get more experience seems like a good thing to work toward, but less from the need for a formalism and more from the perspective of making work practices more widely accessible.

If we need to formally identify these things (say, in a charter), then that should work without saying "use Mode X from Section 5.Y of RFC ZZZZ".  However, now we haven't formalized work modes to that extent so far.  I am not certain if doing that would be a good idea.