[Id-event] Opsdir last call review of draft-ietf-secevent-http-push-10

Joe Clarke via Datatracker <noreply@ietf.org> Thu, 14 May 2020 15:52 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: id-event@ietf.org
Delivered-To: id-event@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23303A0AFB; Thu, 14 May 2020 08:52:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: last-call@ietf.org, id-event@ietf.org, draft-ietf-secevent-http-push.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.130.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158947154667.2243.10642307324359970815@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Thu, 14 May 2020 08:52:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/gTbbGJFV5fIxYoKyrRswYF9ZIKg>
Subject: [Id-event] Opsdir last call review of draft-ietf-secevent-http-push-10
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 15:52:27 -0000

Reviewer: Joe Clarke
Review result: Ready

I have been asked to review this documented on behalf of the Ops Directorate. 
This document describes how to use a push-based method (with HTTP POST) to
deliver Security Event Tokens (SETs).  Overall, I think this document is ready.
 It's easy to read, offers clear examples, and discusses various operational
issues such as processing required and mitigation of potential DoS attacks.  In
my reading of the document, I did find a few nits or things I think may want a
bit more attention:

Section 2:

The phrase "business logic" is nebulous.  It may be sufficient to say,
“anything beyond” the required validation steps.  Then you can say further
logic to processes SETs SHOULD be executed asynchronously.

===

Section 2.3:

In your error examples, especially the second one, is HTTP 400 always the right
error code?  I was thinking 403 in this case.

===

Section 2.4:

Similar to me comment above, should this table have recommended HTTP codes?  I
was thinking invalid_request==422, invalid_key==400,
authentication_failed==403, and access_denied==403.

===

Section 6:

Typo s/Transmistters/Transmitters/