Re: [Gen-art] Genart last call review of draft-ietf-secevent-http-push-10

[Mike Jones <[e-mail]>]

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

-----Original Message-----
From: Vijay Gurbani via Datatracker <[e-mail]> 
Sent: Monday, May 18, 2020 8:17 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Genart last call review of draft-ietf-secevent-http-push-10

Reviewer: Vijay Gurbani
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-secevent-http-push-??
Reviewer: Vijay K. Gurbani
Review Date: 2020-05-18
IETF LC End Date: 2020-05-13
IESG Telechat date: Not scheduled for a telechat

Summary: The document is ready as a Proposed Standard with minor changes as indicated below.

Major issues: 0

Minor issues: 1

Nits/editorial comments: 1

Below, "Sn" denotes "Section n".

- S2, page 4: "The SET Recipient SHOULD NOT perform extensive business logic  that processes the event expressed by the SET prior to sending this  response.  Such logic SHOULD be executed asynchronously from delivery,  in order to minimize the expense and impact of SET delivery on the  SET Transmitter." ==> I understand the need for this normative text,  however, what happens if at some later point from when the SET Recipient  sent a response, the business logic is executed and the logic decides  that the SET is invalid.  What does a SET Recipient do now?  

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."  Should errors be discovered after acknowledgement, the recipient would handle them locally like any other errors encountered.

Nits:

- S2.3, page 7: s/Access token is expired./Access token has expired./
             or s/Access token is expired./Access token expired./
 (Reason: "is" is present tense, "expired" is past, so the grammar in the
 original sentence is incongruous.)

Mike> Thanks.  It now says " Access token has expired".

				Thanks again,
				-- Mike