Skip to main content

Last Call Review of draft-ietf-secevent-http-push-10
review-ietf-secevent-http-push-10-genart-lc-gurbani-2020-05-18-00

Request Review of draft-ietf-secevent-http-push
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-05-13
Requested 2020-04-29
Authors Annabelle Backman , Michael Jones , Marius Scurtescu , Morteza Ansari , Anthony Nadalin
Draft last updated 2020-05-18
Completed reviews Secdir Last Call review of -10 by Valery Smyslov (diff)
Genart Last Call review of -10 by Vijay K. Gurbani (diff)
Opsdir Last Call review of -10 by Joe Clarke (diff)
Secdir Telechat review of -12 by Valery Smyslov (diff)
Assignment Reviewer Vijay K. Gurbani
State Completed
Review review-ietf-secevent-http-push-10-genart-lc-gurbani-2020-05-18
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/7yRQOSzK_Gsz_qKGQbjuKvjPXfs
Reviewed revision 10 (document currently at 14)
Result Ready with Nits
Completed 2020-05-18
review-ietf-secevent-http-push-10-genart-lc-gurbani-2020-05-18-00
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.)