[Gen-art] Gen-ART LC review of draft-ietf-oauth-dyn-reg-management-09

Peter Yee <peter@akayla.com> Mon, 23 March 2015 14:02 UTC

Return-Path: <peter@akayla.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10331A8AB0; Mon, 23 Mar 2015 07:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Level:
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 AtDA0YAPMMRV; Mon, 23 Mar 2015 07:02:43 -0700 (PDT)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id B6A681A8AAA; Mon, 23 Mar 2015 07:02:43 -0700 (PDT)
Received: from [31.133.137.70] ([31.133.137.70]) by p3plsmtpa09-03.prod.phx3.secureserver.net with id 722d1q00M1XJn7B0122gns; Mon, 23 Mar 2015 07:02:43 -0700
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Mon, 23 Mar 2015 07:02:39 -0700
From: Peter Yee <peter@akayla.com>
To: draft-ietf-oauth-dyn-reg-management.all@tools.ietf.org
Message-ID: <D1347500.10079%peter@akayla.com>
Thread-Topic: Gen-ART LC review of draft-ietf-oauth-dyn-reg-management-09
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/D615XBIOA93XXKBhvElnmCbXXG4>
Cc: gen-art@ietf.org, IETF discussion list <ietf@ietf.org>
Subject: [Gen-art] Gen-ART LC review of draft-ietf-oauth-dyn-reg-management-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 14:02:46 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other Last Call comments you
may receive.



Document: draft-ietf-oauth-dyn-reg-management-09
Reviewer: Peter Yee
Review Date: Mar-22-2015
IETF LC End Date: Mar-23-2015
IESG Telechat date: TBD

Summary: This draft is ready for publication as an Experimental RFC, but
has nits that
should be fixed before publication. [Ready with nits]

This specification defines an OAuth client configuration endpoint that be
can be used to manage dynamic client registration updates and the protocol
used to interact with it.

Major issues: None

Minor issues: None

Nits: None


Page 2, section 1, 1st paragraph, 1st sentence: change “at” to “with”.
“At” makes it sound like the client identifier is a server-only object.

Page 5, step (D), change “at” to “to”.

Page 5, step (G), append “or (F)” to the sentence.

Page 5, section 2, 2nd paragraph: this paragraph is wholly subsumed by the
Security Considerations.  Why not just put a pointer to there rather than
duplicate the text?

Page 6, section 2.2: while not technically incorrect, I would argue that
the update is being made to the server by the client, albeit with the
server’s permission.  Thus I find the wording of this first sentence
somewhat misleading.  Perhaps a rewrite would help?  I find the use of “at
the server” in the document allows a lot of looseness that encourages
varying interpretations of what is meant.

Page 7, 1st paragraph: remove the space in “top- level”.

Page 7, 2nd paragraph, 2nd sentence: change “client” to “updated client
metadata fields”.  This is to make it clear the client must not include
the forbidden fields in the updated fields it presents, but that most
certainly items like the registration access token will be part of the
request.

Page 12, last paragraph, last sentence: clarify disclosure of what?
Wasn't the deprovisioning process supposed to delete or make unavailable
the metadata?  So other than not having canceled the registration access
token, what's to be disclosed?

Page 15, section B.1, 1st sentence: change “token” to “tokens”.

Page 15, section B.1, 2nd sentence: change “map” to “may”.