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

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-secevent-http-push-12: 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-push/



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

— Section 1 —
I agree with Éric’s comment that “known to one another” should be better
explained — just something brief.

   Push-based SET delivery over HTTP POST is intended for scenarios
   where all of the following apply:

Is it the intent that push be used in all such cases, and pull in all others? 
It would be good to explicitly say that, perhaps by adding “(with pull-based
SET delivery used in all other cases)” to the above.

— Section 2 —

   o  The SET is authentic (i.e., it was issued by the issuer specified
      within the SET, and if signed, was signed by a key belonging to
      the issuer).

If the SET is not signed, how is authenticity determined and validated?  I
understand that the specifics are out of scope for this document, but I’m
trying to understand in general how this works.

   o  The SET Issuer is recognized as an issuer that the SET Recipient
      is willing to receive SETs from (e.g., the issuer is whitelisted
      by the SET Recipient).

Let’s get a head start on the movement away from “whitelist/blacklist” and
change this to “is listed as allowed by the SET Recipient”, or some such.  What
do you think?

   o  The SET Recipient is willing to accept the SET when transmitted by
      the SET Transmitter (e.g., the SET Transmitter is expected to send
      SETs with the subject of the SET in question).

It took me a couple of reads to understand what this is getting at.  Maybe this
clarifies a little?:

NEW
   o  The SET Recipient is willing to accept this SET from this SET
      Transmitter (e.g., the SET Transmitter is expected to send
      SETs with the subject of the SET in question).
END

   The SET Transmitter MAY re-transmit a SET if the responses from
   previous transmissions timed out or indicated potentially recoverable
   error

Nit: “errors”

— Section 2.1 —

   To transmit a SET to a SET Recipient, the SET Transmitter makes an
   HTTP POST request to an HTTP endpoint using TLS provided by the SET
   Recipient.

How is TLS provided by the SET Recipient?
Or, perhaps, do you mean, “makes an HTTP POST request using TLS to an HTTP
endpoint provided by the SET Recipient.”?

— Section 2.2 —

   Before acknowledgement, SET Recipients SHOULD ensure they have
   validated received SETs

Section 2 says, “Upon receipt of a SET, the SET Recipient SHALL validate”, so
how does that work with the SHOULD here?  I think this is a problem with
repeating normative statements: making sure they remain completely consistent.

— Section 2.4 —

   |                       | unacceptable to the SET Recipient. (e.g., |
   |                       | expired, revoked, failed certificate      |
   |                       | validation, etc.)                         |

Nit: “e.g.” and “etc.” used together is redundant; I suggest removing the
former.

   Implementations SHOULD expect that other Error Codes may also be
   received, as the set of Error Codes is extensible

I suggest not using a 2119 key word here.  This isn’t really a SHOULD: an
implementation that can’t tolerate extensions will be limited and eventually
considered broken.  I think it’s better to just say this as a statement,
beginning the sentence with the word “Other”.

— Section 3 —

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

Is DANE (RFC 6698) not allowed?  Or should this be worded differently?  This
also applies to the reference to cert validation in Section 5.3.

— Section 7.1 —

   Future assignments are to be made
   through the Specification Required registration policy

Please provide some brief guidance to the designated experts.  Thanks.

— Section 7.1.1 —

   Change Controller
      For error codes registered by the IETF or its working groups, list
      "IETF SecEvent Working Group".

Nit: This isn’t consistent with Section 7.1.2, nor with current practice.  It
should just say “IETF”.