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? 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.) -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
