[art] Artart last call review of draft-ietf-privacypass-protocol-12

Yoshiro Yoneya via Datatracker <noreply@ietf.org> Wed, 30 August 2023 06:23 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7DC1519A5; Tue, 29 Aug 2023 23:23:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoshiro Yoneya via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-privacypass-protocol.all@ietf.org, last-call@ietf.org, privacy-pass@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169337660081.2117.18151104746675284233@ietfa.amsl.com>
Reply-To: Yoshiro Yoneya <yoshiro.yoneya@jprs.co.jp>
Date: Tue, 29 Aug 2023 23:23:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU>
Subject: [art] Artart last call review of draft-ietf-privacypass-protocol-12
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Aug 2023 06:23:20 -0000

Reviewer: Yoshiro Yoneya
Review result: Ready with Nits

Reviewer: Yoshiro Yoneya
Review result: Ready with Nits

  I am assigned ARTART reviewer for this draft.

Summary:

  This draft is in good shape and almost ready for publication.  I found a few
  nits better to be considered.

Major issues:

  None.

Minor issues:

  None.

Nits:

  ==
  In Section "4. Configuration":

  CURRENT
  1.  Issuer Request URL: A token request URL for generating access
       tokens.  For example, an Issuer URL might be
       https://issuer.example.net/request.

  SUGGESTION
  1.  Issuer Request URI: A token request URI for generating access
       tokens.  For example, an Issuer URI might be
       https://issuer.example.net/request.

  This is because URI is normative term for URL in IETF.
  I found the term "URL" in this document at several places and they could be
  replaced by "URI" as well.

  ==
  In Section "5.1. Client-to-Issuer Request":

  CURRENT
  *  "token_type" is a 2-octet integer, which matches the type in the
      challenge.

  SUGGESTION
  *  "token_type" is a 2-byte integer, which matches the type in the
      challenge.

  There seems no reason to use the term "octet" in this document. By definition
  of the data structure, byte == 8bit (uint8_t) is obvious. I found the term
  "octet" in this document at several places and they could be replaced by
  "byte" as well.