Re: [Ace] Murray Kucherawy's No Objection on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

Stefanie Gerdes <gerdes@tzi.de> Tue, 11 May 2021 12:41 UTC

Return-Path: <gerdes@tzi.de>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D373A1626; Tue, 11 May 2021 05:41:26 -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, NICE_REPLY_A=-0.001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no 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 Hehy1U2x-eUZ; Tue, 11 May 2021 05:41:23 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 804E53A1620; Tue, 11 May 2021 05:41:23 -0700 (PDT)
Received: from [192.168.0.48] (p5b36f986.dip0.t-ipconnect.de [91.54.249.134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ffcwv1cBMz315X; Tue, 11 May 2021 14:41:19 +0200 (CEST)
To: Murray Kucherawy <superuser@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-ace-dtls-authorize@ietf.org, ace-chairs@ietf.org, ace@ietf.org
References: <161664651707.11716.2055218120947993457@ietfa.amsl.com>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <c17cb1da-55b9-cd6a-cba4-7a8e7294c75d@tzi.de>
Date: Tue, 11 May 2021 14:41:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <161664651707.11716.2055218120947993457@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/cnFAa0qnB_Cr03OkJ10vX27mmcI>
Subject: Re: [Ace] Murray Kucherawy's No Objection on draft-ietf-ace-dtls-authorize-16: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2021 12:41:27 -0000

Hi Murray,

Thank you for your comments, and sorry for the late reply. We addressed
most of the issues in the latest version, but I have one comment (see
below).

On 3/25/21 5:28 AM, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ace-dtls-authorize-16: No Objection
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In Section 3.2.2, first paragraph, why is that only a SHOULD?  What's a
> situation in which I might do something else?  Same for the one in the second
> paragraph of Section 3.4.

I agree that the phrasing in 3.2.2 is a bit odd. We rephrased that sentence.

In section 3.4, I guess you refer to the sentence "New access tokens
issued by the authorization server SHOULD replace previously issued
access tokens for the respective client." The reason for this phrasing
is that while we recommend that the RS only has a single access token
per client, it is not forbidden to have several (see also section 5.10.1
of draft-ace-oauth-authz). Applications may, e.g., decide to let the AS
add new permissions to the existing ones.

> 
> In the last paragraph of Section 3.3.1, "additionally" doesn't need to appear
> twice.

Okay, fixed.

Thank you for your time,
Steffi