RE: Genart last call review of draft-weis-gdoi-rekey-ack-05

[Roni Even <roni.even@xxxxxxxxxx>]

Hi Brian,

Thanks

OK now

Roni

 

From: Gen-art [mailto:gen-art-bounces@xxxxxxxx] On Behalf Of Brian Weis (bew)
Sent: יום ב 24 יולי 2017 19:18
To: Roni Even
Cc: draft-weis-gdoi-rekey-ack.all@xxxxxxxx; gen-art@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: [Gen-art] Genart last call review of draft-weis-gdoi-rekey-ack-05

 

Hi Roni,

 

Thanks for your helpful review.

 

On Jun 26, 2017, at 1:03 AM, Roni Even <ron.even.tlv@xxxxxxxxx> wrote:

 

Reviewer: Roni Even
Review result: Almost Ready

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?

 

After conferring, the authors believe that the real reason for a GM to ignore KEK_ACK_REQUESTED

is because they do not support it. As such, we’ve adjusted the wording in several places to say this. 

And with that wording  it makes sense for the SHOULD to become 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?

 

We’ve clarified that reliability is most likely to come from transmitting the GROUPKEY-PUSH message

several times. This comes from a recommendation in RFC 4046, and we’ve made this more explicit.

 

      The GCKS MAY be configured with additional policy actions such as

      transmitting the GROUPKEY-PUSH message several times in a short

      period of time (as suggested in [RFC4046]), which mitigates a

      packet loss of either the GROUPKEY-PUSH message or an

      Acknowledgement message. 

 

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

 

There was a “not” missing. The sentence now reads

 

   Also a GM may not be able to respond with an GROUPKEY-PUSH ACK.

 

Let us know if these don’t sufficiently address your points.

 

Thanks,

Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@xxxxxxxxx