Vijay, thanks for your review. Mike, thanks for addressing his comments. I entered a No Objection ballot.
Alissa > On Jun 8, 2020, at 8:41 PM, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > 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 <nore...@ietf.org> > Sent: Monday, May 18, 2020 8:17 AM > To: gen-art@ietf.org > Cc: draft-ietf-secevent-http-push....@ietf.org; last-c...@ietf.org; > id-ev...@ietf.org > 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 > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
