[saag] Review for https://datatracker.ietf.org/doc/draft -deshpande-secevent-http-multi-set-push/

Here are my comments:
Section 3: “In this SET delivery using HTTP over TLS, *zero* or more SETs
are delivered”
 – Is there a reason why it is zero and not one? What is the use case for
sending zero SETs?

Section 3.1: “A *Transmitter* MUST ensure that it includes the jti value of
each SET it receives”
 – It should be “A Receiver” not “A Transmitter”

Section 3.2: “If a Transmitter wishes to re-send an event after it has
received a error response through a setErrs value, then it MUST generate a
new SET that has a new (and unique) jti value”
 - Typo: “an error” instead of “a error”
 - Creating a new set for the same event may have cost for the transmitter
and if the SET is for the same event and presumably have the same content
why do you want the transmitter to create a new SET for it?

Section 4: “The Transmitter *SHOULD* attempt to obtain the OAuth Protected
Resource Metadata [RFC9728
<https://www.ietf.org/archive/id/draft-deshpande-secevent-http-multi-set-push-00.html#RFC9728>]
for the Receiver's Push-Based delivery for multiple SETs endpoint. If such
metadata is found, the Transmitter *MUST* obtain an access token using the
metadata”
 - Why the spec specifically requires the use of “OAuth Protected Resource
Metadata” instead of leaving it for the transmitters and receivers to agree
upon?

Section 5: “A Transmitter *MUST* attempt to deliver any SETs it has
previously attempted to deliver to a Receiver until: “
 - The use of MUST in this section when the maximum number of times can be
one (i.e., no retries will be attempted) is a little misleading. You should
consider using SHOULD instead or clarify that the maximum number of times
must be greater than one (which I don’t think is the right thing to do).

General comment on the acknowledge mechanism: The spec defines a mandatory
asynchronous acknowledge mechanism. This mechanism complicates the
processing of events both for the transmitter and for the receiver. I can
see the value in guaranteeing that every event is acknowledged and
processed but I can also expect it to be an overkill in many situations
where other factors may prevent the delivery and processing of events. I
would suggest making the acknowledgment optional.

Yair Sarig.

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]