[GNAP] GNAP Editors' Use of GitHub Issues

Aaron Parecki <aaron@parecki.com> Wed, 25 November 2020 16:36 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0F93A1A27 for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 08:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
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 jomSC1wcgxAA for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 08:36:52 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583D83A1A20 for <txauth@ietf.org>; Wed, 25 Nov 2020 08:36:52 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id r9so2740876ioo.7 for <txauth@ietf.org>; Wed, 25 Nov 2020 08:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=l1kmn6gkNMdAPdihwPtwHAicqtuYY6hx7XdDq2kly/4=; b=jVacd2DOMgyUSkOFzoGmF7wqQQgabbUGb8hrImOJLPR6LkiLoKfwQvg+9qO3ET9Rjp mGylR3so4TdMjiStpdJip+nAWST0wVxsZTXO86Bl38dXwCR7kc56MDhzCufOmoYcxItX 8bcp9dmGAJRkGsCiUzL6Me/aNuOz88rjkHnVnD9dNGStKcC5UxEqmmas1rJiOKNcoH1u /1fLBnGM4+5b/0Qqc5hgHChHhoRTaMsysOypLYEwjnJXcSG8XF3ehwLy0qCqDXHpay1w OsBnNsW7Gw0J+LkMkXqqL9Vy1hb6p2NbnGzDsurFY+5jV4jRlWfB97j2K02NfQMIIHYX Filw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l1kmn6gkNMdAPdihwPtwHAicqtuYY6hx7XdDq2kly/4=; b=ijLsfsL5zJsxJgeTp5Ow1gra1iy1wbXvvh8TyRH6xqXfdaOjM/p+uYm2YTD+3l0zeZ 9zxLZMNe7Lo401mojWi0DZEapaoBIEGD52rb5LWS315nkV8/IspOrpSp48y/IooleE9O L3aj9A+U4OQKnVEjFXlZ+WQlmibQS+/KuHDHXI3xMaInPoYYi6mHdQ9r4mdd/1ERYdfC YzCMHJzoMDg9kI2RRTvJ4arNGW56SQFCCGn6WhdWfgaApJ+9lM8qxNJTIM1I9fZ4JlfB wmJiXhkBGwUHcE2L15Xp7f4pk6seoluuSVDAUFsofP/nJ4ABW3Kio21XftnORqmWUvjZ kmVg==
X-Gm-Message-State: AOAM533pXmaZI+eM1QKDWFIMnB5IDnmAaxPG2oYGtTRbPU2UO6AL0dCX Fiq/oMmN/N0et+7fAyZE03uqdSbBr2wRCQ==
X-Google-Smtp-Source: ABdhPJzDn9WqdJA+XIb2AJOpmKHMUVKQO/9sahXt6H20Lgqk35dxcOPV6cXS9PukD9Fk+oXsv4e1UQ==
X-Received: by 2002:a6b:3756:: with SMTP id e83mr3256561ioa.127.1606322210515; Wed, 25 Nov 2020 08:36:50 -0800 (PST)
Received: from mail-il1-f175.google.com (mail-il1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id p28sm1830713ilb.9.2020.11.25.08.36.49 for <txauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 08:36:49 -0800 (PST)
Received: by mail-il1-f175.google.com with SMTP id t13so2714971ilp.2 for <txauth@ietf.org>; Wed, 25 Nov 2020 08:36:49 -0800 (PST)
X-Received: by 2002:a92:ab0f:: with SMTP id v15mr3663403ilh.17.1606322208903; Wed, 25 Nov 2020 08:36:48 -0800 (PST)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 25 Nov 2020 08:36:37 -0800
X-Gmail-Original-Message-ID: <CAGBSGjqi8FdQg6RS_tpbW-R1JzeWiwKnJ2ObVxwMOkAbHaaJ_Q@mail.gmail.com>
Message-ID: <CAGBSGjqi8FdQg6RS_tpbW-R1JzeWiwKnJ2ObVxwMOkAbHaaJ_Q@mail.gmail.com>
To: GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a81a2705b4f1089e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/PZN90foQWcJlxLxjW5VwT0zcHXE>
Subject: [GNAP] GNAP Editors' Use of GitHub Issues
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2020 16:36:55 -0000

The editors met yesterday to discuss the issues that were pulled out of the
previous draft text and document a process for how to resolve these and
future issues. We would like to explain how we plan on using labels on
GitHub issues to keep track of discussions and keep things moving.

When there are substantive issues or pull requests, the editors will avoid
merging or closing those outright, and instead mark them as "pending", so
that these can be brought to the attention of the larger group. If no
additional discussion happens on these, the merge or close action will be
taken in 7 days. Note for this first round we are setting the deadline for
the issues below as Dec 11th due to the US holiday and the fact that this
is the first time using this process.

"Pending Merge"
When specific text is proposed in a PR (by anyone, not limited to the
editors), and the editors believe this text reflects the consensus of the
working group, this marks that the PR will be merged in 7 days unless there
is a clear alternative proposal accepted by the working group.

"Pending Close"
When the editors believe an issue no longer needs discussion, we'll mark it
"Pending Close". The issue will be closed in 7 days unless someone brings
new information to the discussion. This tag is not applied to issues that
will be closed by a specific pull request.

There are two additional labels we will use to flag issues to the group.

"Needs Text"
The editors suggest this issue needs additional text in the spec to clarify
why this section is needed and under what circumstances. Without a concrete
proposal of text to be included in the spec, this section will be removed
in a future update.

"Postponed"
This issue can be reconsidered in the future with a more concrete
discussion but is not targeted for immediate concrete changes to the spec
text. When used on its own, this label does not indicate that an issue is
targeted to be closed. An issue may also be marked "Pending Close", and
this is used so that we can distinguish closed issues between discussions
that have concluded or things that we may want to revisit in the future.
Remember that closed issues are not deleted and their contents are still
findable and readable, and that new issues can reference closed issues.

With these labels in mind, here are the list of issues and their statuses
we were able to discuss on our last editor's call. The action on these
pending issues will be taken on Dec 11th to give the group enough time to
review this list. For this first round, many of the issues are marked
"Pending Close" as we're looking for low hanging fruit to prune the list of
issues down. In the future, you can expect to see more "Pending Merge"
issues as we're bringing proposed text to review by the WG.

Postponed:

* Generic claim extension mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Pending Merge:

* Make access token mandatory for continuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129

Postponed and Pending Close:

* Fetchable Keys
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Application communication with back-end
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interaction protocols
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:

* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with unique callback URL
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expanding dynamic reference handles
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interaction callback nonce
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance identifier
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources by reference
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Mapping resource references
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35

---
Aaron Parecki
https://aaronparecki.com