Re: [Id-event] Barry Leiba's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)

[Mike Jones <[e-mail]>]

Thanks for your review, Barry.  https://tools.ietf.org/html/draft-ietf-secevent-http-poll-12 is intended to address your comments.  Detailed replies are inline, prefixed by "Mike>".

-----Original Message-----
From: Barry Leiba via Datatracker <[e-mail]> 
Sent: Wednesday, June 24, 2020 1:42 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>; [e-mail]
Subject: Barry Leiba's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-secevent-http-poll-11: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

— Section 1 —
Section 1 of the push draft explains that push is meant to be used under specific circumstances.  Is it the intent that push be used for those cases, and pull be used for everything else?  It might be good to say that explicitly here, perhaps as, “This is an alternative SET delivery method to the one defined in [I-D.ietf-secevent-http-push], and is used for cases where push-based delivery does not apply.”

Mike> The Poll draft now has a parallel applicability statement to that in the Push draft.

— Section 2 —

   The SET Recipient MUST acknowledge
   receipt to the SET Transmitter, and SHOULD do in a timely fashion

Nit: “SHOULD do so”

Mike> Done

— Section 2.1 —

   Before acknowledgement, SET Recipients SHOULD ensure that received
   SETs have been validated

Same comment as in -push: validation is a SHALL, and this says SHOULD.  But see my comment below for Section 2.4.

Mike> Reworded to eliminate the gratuitous SHALLs and SHOULDs

— Section 2.2 —

      maxEvents
         An OPTIONAL JSON integer value indicating the maximum number of
         unacknowledged SETs that SHOULD be returned.

The antecedent to SHOULD is unclear.  Are you really saying that the SETs SHOULD be returned?  Or do you mean that the SHOULD applies to the maximum number?  Assuming the latter, it’s better said this way:

NEW
      maxEvents
         An OPTIONAL JSON integer value indicating the maximum number of
         unacknowledged SETs to be returned.  The SET Transmitter SHOULD
         NOT send more SETs than the specified maximum.
END

Mike> Thanks - done

         Recipients that would like to perform an acknowledge only
         request.

Nit: hyphenate “acknowledge-only”

Mike> Done here and in other parallel locations

— Section 2.4 —

   If the SET Recipient has received SETs from the SET Transmitter, the
   SET Recipient SHOULD parse and validate received SETs

Is it intended that validation is a SHALL in push and a SHOULD in pull?  If so, why?  Is it worth explaining that in the documents?

Mike> Reworded as above

— Section 3 —

   The TLS server certificate
   MUST be validated, per [RFC6125].

Same comment as in -push: what about DANE?  (Also for Section 4.3)

Mike> Dane is now explicitly allowed

				Thanks again,
				-- Mike