Last Call Review of draft-weis-gdoi-rekey-ack-05
review-weis-gdoi-rekey-ack-05-genart-lc-even-2017-06-26-00
| Request | Review of | draft-weis-gdoi-rekey-ack |
|---|---|---|
| Requested revision | No specific revision (document currently at 07) | |
| Type | IETF Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2017-07-17 | |
| Requested | 2017-06-19 | |
| Authors | Brian Weis , Umesh Mangla , Thomas Karl , Nilesh Maheshwari | |
| I-D last updated | 2017-11-30 (Latest revision 2017-09-08) | |
| Completed reviews |
Secdir IETF Last Call review of -05
by Yaron Sheffer
(diff)
Genart IETF Last Call review of -05 by Roni Even (diff) Opsdir IETF Last Call review of -05 by Zitao Wang (diff) Genart Telechat review of -06 by Roni Even (diff) |
|
| Assignment | Reviewer | Roni Even |
| State | Completed | |
| Request | IETF Last Call review on draft-weis-gdoi-rekey-ack by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 05 (document currently at 07) | |
| Result | Almost ready | |
| Completed | 2017-06-26 |
review-weis-gdoi-rekey-ack-05-genart-lc-even-2017-06-26-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-weis-gdoi-rekey-ack-?? Reviewer: Roni Even Review Date: 2017-06-26 IETF LC End Date: 2017-07-17 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as standard track document Major issues: Minor issues: 1. In section 2 it says "A GM receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus appearing as if it does not support the KEK_ACK_REQUESTED attribute.". Any reason for the GM to ignore the message? 2. In section 4 and section 6 it says the the GM SHOULD send an acknowledgement message. Is there a case when the GM should not send and if not why is this a SHOULD and not a MUST? 3. In section 6 "A non-receipt of an Acknowledgement is an indication that a GM is either unable or unwilling to respond". What about if the Acknowledgement message was lost? Any reliability procedure? Nits/editorial comments: 1. In section 6 "Also a GM may be willing or able to respond with an GROUPKEY-PUSH ACK " . I cannot parse this sentence in the context of the section