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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 24 Jun 2020 13:42:00 -0700

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.”

— Section 2 —

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

Nit: “SHOULD do so”

— 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.

— 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

         Recipients that would like to perform an acknowledge only
         request.

Nit: hyphenate “acknowledge-only”

— 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?

— Section 3 —

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

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Jun 2020 05:59:04 +0000

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 <[email-masked]> 
Sent: Wednesday, June 24, 2020 1:42 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Yaron Sheffer <[email-masked]>; [email-masked]
Subject: Barry Leiba's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)

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.)

— 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 —

Nit: “SHOULD do so”

Mike> Done

— Section 2.1 —

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

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

Mike> Thanks - done

Mike> Done here and in other parallel locations

— Section 2.4 —

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 —

Mike> Dane is now explicitly allowed

				Thanks again,
				-- Mike