Skip to main content

Last Call Review of draft-weis-gdoi-rekey-ack-05

Request Review of draft-weis-gdoi-rekey-ack
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-07-17
Requested 2017-06-19
Authors Brian Weis , Umesh Mangla , Thomas Karl , Nilesh Maheshwari
I-D last updated 2017-08-01
Completed reviews Secdir Last Call review of -05 by Yaron Sheffer (diff)
Genart Last Call review of -05 by Roni Even (diff)
Opsdir Last Call review of -05 by Zitao Wang (diff)
Genart Telechat review of -06 by Roni Even (diff)
Assignment Reviewer Zitao Wang
State Completed
Request Last Call review on draft-weis-gdoi-rekey-ack by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2017-08-01
Reviewer: Zitao Wang (Michael)

Review result: Has Nits

I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document reviewed:  draft-weis-gdoi-rekey-ack-05


The Group Domain of Interpretation (GDOI) includes the ability for a Group
Controller/Key Server (GCKS) to provide a set of current Group Member (GM)
devices with additional security associations (e.g., to rekey expiring security
associations). This memo adds the ability of a GCKS to request the GM devices
to return an acknowledgement of receipt of its rekey message, and specifies the
acknowledgement method.

I think the document make sense and is written very clear, except some small

Page 2:     The second paragraph of introduction-- “A GDOI GCKS uses a
GROUPKEY-PUSH message to alert...”.

I suggest adding a reference that the reader can easy refer to this message.

Page 7:     3.1 HDR -- "Next Payload identifies a Hash payload (8)."

I suggest mollifying (8) to (value 8), and adding a reference like "section 5
of [rfc6407]"

Page 10:              “A GM MAY introduce a jitter to the timing of its
Acknowledgement message to help the GCKS better manage replies from group
members. The jitter SHOULD be no more than a few seconds.”
            How to measure this jitter? How to know if the 'jitter' satisfy the

A run of idnits revealed there were 1 error, 1 warning and 2 comments:

  == Outdated reference: draft-weis-gdoi-iec62351-9 has been published as RFC

  ** Obsolete normative reference: RFC 5226

  -- Obsolete informational reference (is this intentional?): RFC 2408
     (Obsoleted by RFC 4306)

     Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).