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 <noreply@xxxxxxxx> Sent: Monday, May 18, 2020 8:17 AM To: gen-art@xxxxxxxx Cc: draft-ietf-secevent-http-push.all@xxxxxxxx; last-call@xxxxxxxx; id-event@xxxxxxxx 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
