[Rum] Benjamin Kaduk's No Objection on draft-ietf-rum-rue-10: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Sun, 06 February 2022 19:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rum@ietf.org
Delivered-To: rum@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBD73A0C42; Sun, 6 Feb 2022 11:17:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rum-rue@ietf.org, rum-chairs@ietf.org, rum@ietf.org, pkyzivat@alum.mit.edu, pkyzivat@alum.mit.edu
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <164417503717.5136.3087973274819872696@ietfa.amsl.com>
Date: Sun, 06 Feb 2022 11:17:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/KjfTvO0dOTShtveO_aPXmpxCojA>
Subject: [Rum] Benjamin Kaduk's No Objection on draft-ietf-rum-rue-10: (with COMMENT)
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Feb 2022 19:17:18 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-rum-rue-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks for the updates in the -10; we look to be nice and
self-consistent (modulo carddav-domain, see below) now.

I especially like the example passwords -- good entropy there :)

There are some editorial/formatting nits that crept in, but I'm sure the
RFC Editor can fix those up and didn't bother enumerating them here.

A few final comments/suggestions:

The description of "carddav-domain" uses "server address" in the OpenAPI
description string but in the prose description we call it
"contacts-domain" (not "carddav-domain") and we describe it as just "a
domain name" (vs address).  It would be good to tighten those up into closer alignment.

Section 9.2

   The data returned is a JSON object consisting of an array of key/
   value configuration parameters to be used by the RUE.

s/consisting of an array of/consisting of/, I think -- the openAPI looks
like just an object, no array.

Section 9.2.2

   *  contacts: (optional) An HTTPS URI ("contacts-uri"), (optional)
      user name ("contacts-username") and password ("contacts-password")
      that may be used to export (retrieve) the subscriber's complete
      [...]
   *  carddav: (optional) A domain name ("contacts-domain"), (optional)
      user name ("carddav-username") and password ("carddav-password")
      identifying a "CardDAV" server and account that can be used to

I'd go with "An object containing [URI/domain name], and optional [user
name and password]," for both of these.  The OpenAPI description is clear
(and authoritative, thanks for that!), but this is an easy tweak to help
readability.