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

From: Mike Jones <[email-masked]>
Date: Tue, 9 Jun 2020 00:49:44 +0000

Thanks for your useful review, Joe.  I've attempted to address your comments in https://tools.ietf.org/html/draft-ietf-secevent-http-push-11.  My comments are inline, prefixed by "Mike>".

-----Original Message-----
From: Joe Clarke via Datatracker <[email-masked]> 
Sent: Thursday, May 14, 2020 8:52 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Opsdir last call review of draft-ietf-secevent-http-push-10

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.

Mike> I've updated the sentence to read "The SET Recipient SHOULD NOT perform anything beyond the required validation steps prior to sending this response."

===

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.

Mike> The second paragraph of https://tools.ietf.org/html/draft-ietf-secevent-http-push-11#section-2.3 states "the SET Recipient SHALL respond with an HTTP Response Status Code of 400 (Bad Request)".  While other error codes could have been used or allowed, choosing one to keep things simple and interoperable was the goal here.

===

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.

Mike> See above

===

Section 6:

Typo s/Transmistters/Transmitters/

Mike> Thanks - fixed!

				Thanks again,
				-- Mike

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 9 Jun 2020 15:36:38 +0000

> Mike> I've updated the sentence to read "The SET Recipient SHOULD NOT perform anything beyond the required validation steps prior to sending this response."

WFM.  Thanks.

> Mike> The second paragraph of https://tools.ietf.org/html/draft-ietf-secevent-http-push-11#section-2.3 states "the SET Recipient SHALL respond with an HTTP Response Status Code of 400 (Bad Request)…

Hmmm, I must have just glossed over this bit on my first read (sorry).  I’ve gone back and re-read.  I would think you could still standardize and be interoperable with more purposeful codes, but I will defer to those more in the HTTP know here.  The JSON response fleshes out the specifics, so it’s a minor thing.

Joe