Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 17 December 2015 03:02 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 87FE61A1A82; Wed, 16 Dec 2015 19:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 GkGT32Qro-Xd; Wed, 16 Dec 2015 19:02:38 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 426F61A1A7F; Wed, 16 Dec 2015 19:02:38 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id p187so2311693wmp.0; Wed, 16 Dec 2015 19:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/1JBzpkWSZZomlubuTBq/7m0SyKjlVHKfn9NtGd3aTA=; b=0K/IMsh4TlpA2S2ij2XyJRMpdh4d6jp8vXYgExSW70+ePER6DfqzKdyD/KbYrwFt7y 6rMHI0ks+mda0ZM1w/+pgfCBeMIXLMQqBQsHINIeCADXtZBhu5x4yBTSE7EvyabjyYOr zAkAllnn+EZRv1ZgfRrM3WGRGMUN25QuuwCYxyRwYijVfzwc4LKKxm96JHCDSHWwi4Ai yy0beakbw/FrZXxFpG3ehC6c3ie1cmnlRdcZujH29A6AFsxcqUetPpDf6l8JpiIGFpRp k/qtbbZuXuG8YqLBZ5fTOti9etMh1gM85Zq0MZlwGQY8q3c4mYypQOyA5wisH+OPuytu gy+g==
MIME-Version: 1.0
X-Received: by 10.194.222.195 with SMTP id qo3mr53778117wjc.51.1450321356944; Wed, 16 Dec 2015 19:02:36 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Wed, 16 Dec 2015 19:02:36 -0800 (PST)
In-Reply-To: <2A457E0F-1ADC-4C4A-B6C8-3B29DEF46BAF@cisco.com>
References: <2A457E0F-1ADC-4C4A-B6C8-3B29DEF46BAF@cisco.com>
Date: Wed, 16 Dec 2015 22:02:36 -0500
Message-ID: <CAHbuEH6TXnXdiFsyCStAZmOFwEEvoBWbf_DdSX7a3m=CW1FJag@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/wlBc6RPqTk8eq3QpK6CwQDBSuDQ>
Cc: "draft-ietf-oauth-pop-architecture.all@ietf.org" <draft-ietf-oauth-pop-architecture.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 03:02:40 -0000

Hi Matt,

Thank you for your review!  The editors will take these comments into
consideration and discuss any updates.  I'll note that the draft was
pulled from the telechat and will likely not go through last call
again until sometime around Buenos Aires due to some other changes
that came up.  You may see this one again.

Thanks,
Kathleen

On Wed, Dec 16, 2015 at 9:28 PM, Matt Miller (mamille2)
<mamille2@cisco.com> wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-oauth-pop-architecture-07
> Reviewer: Matthew A. Miller
> Review Date: 2015-12-16
> IETF LC End Date: 2015-12-15
> IESG Telechat date: 2015-12-17
>
> Summary: Almost ready.
>
> I have several editorial nits, but also a couple of minor concerns that
> I think would improve this document's readability.
>
> I note that idnits complained about the lack of RFC 2119 boilerplate;
> however, I think the text actually used in this document is most
> appropriate and still conveys the intent.  The idnits also complained
> about a reference to an obsolete RFC 5849; however, this reference
> appears to be intentional and necessary.
>
> -----
>
> Major issues:
>
> Nnne.
>
> Minor issues:
>
> 1. In Section 1. Introduction, the last paragraph makes it seem the
> document isn't organized properly.  It implies an order to read the
> document that is not reflected in the outline:
>
>  * Section 1
>  * Section 2
>  * Section 3
>  * Section 4
>  * Section 6
>  * Section 7
>  * Section 5
>
> Simply re-ording the document I think causes bigger problems.  While
> the intro hints at the order to read, it makes more sense to me in
> the order it actually is.  Ultimately, for me the problem arises with
> the word "concludes".  It might simply be enough to change the last
> participle from ", and concludes with a requirements list in Section 5."
> to ", and lists requirements in Section 5."
>
> 2. In several places, terms of art are used that have not been defined
> in this document: "resource server", "protected resource", etc.  I
> think it would help if Section 2. indicated where these terms are
> defined or discussed, which is RFC 6749.
>
>
> Nits/editorial comments:
>
> * The reference to draft-ietf-oauth-proof-of-possession-08 should be
> updated to its latest version, although I expect RFC Editor will
> resolve this before publication.
>
> * The reference to RFC 4347 should be updated to 6347; there's no clear
> requirement for the older document.
>
> * In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
> "with other resource server" should be either "with another resource
> server" or "with other resource servers".
>
> * In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
> should be "entity".
>
> * In section 3.4 Offering Application Layer End-to-End Security, The
> last sentence of the last paragraph seems out of place.  It seems it
> would be better as the penultimate sentence of the previous paragraph.
>
> * In section 4. Security and Privacy Threats under "Token
> manufacture/modification", "causing resource server" should be "causing
> the resource server".
>
> * Also in Section 4. Security and Privacy Threats under "Token
> manufacture/modification", the normative language here seems out of
> place.  It seems to me that 'may' conveys just as much as 'MAY' for
> how it is used here.
>
> * In Section 5. Requirements under "Prevent the Domino Effect",
> "Resource Server" is capitalized differently than all previous uses,
> but it doesn't seem to be a different use.  I suggest changing it to
> "resource server".
>
> * In Section 6.3. Key Confirmation, uses the term "privacy key" where
> I believe the common nomenclature is "private key".
>
> * In Section 7. Client and Authorization Server Interaction, I find
> most of the figures a little hard to follow.  While I appreciate the
> attempt to go beyond strict perpendicularity, I find it distracting
> from the information it is trying to convey.
>
> * In Section 7.1 Symmetric Keys, I think the "three ways for
> communicating this session key" would benefit having bullets or
> outline numbers.
>
> * In Section 10. Acknowledgements, the second paragraph discusses an
> appendix that borrows content from another document, but there is no
> appendix in this draft.  Is this text still relevant?
>
>
> --
> - m&m
>
> Matt Miller
> Cisco Systems, Inc.
>



-- 

Best regards,
Kathleen