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

Barry Leiba via Datatracker <noreply@ietf.org> Wed, 24 June 2020 20:42 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-secevent-http-poll@ietf.org, secevent-chairs@ietf.org, id-event@ietf.org, Yaron Sheffer <yaronf.ietf@gmail.com>, yaronf.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <159303132054.18572.17703091513176765625@ietfa.amsl.com>
Date: Wed, 24 Jun 2020 13:42:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/EN37EIY7QA0YtkWPfGIPYNTibzA>
Subject: [Id-event] 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.”

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

[Id-event] Barry Leiba's No Objection on draft-ie… Barry Leiba via Datatracker
Re: [Id-event] Barry Leiba's No Objection on draf… Mike Jones