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

Hi Yair, thank you for your review. Responses are inline.

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?


This is described later down in section 3.3, but this allows the
Transmitter to request ack/errs for previously sent SETs even when it has
no new SETs to send itself. We will add this clarifying statement at the
top of section 3 to clarify.

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”


Thanks, this has been corrected.

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?


The prior sentence says that the SET was acknowledged either successfully
or with an error response, so the SET transaction is complete. If the
Transmitter wants to send the same values in a new event it would be a new
SET.

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?


The authors discussed this and will remove this reference, allowing
transmitter and receivers to agree on the mechanism between themselves.

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


The 3 bullet points are describing the conditions under which retries will
stop, it doesn't sound problematic to me to leave it like this.

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.


The acknowledgment is not optional, it is core to what is being defined by
this draft.

---
Aaron Parecki

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