Subject: [Id-event] Comments: draft-ietf-secevent-http-push-00

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Jun 2018 00:05:01 +0300

Dear authors, I just reread the draft, for the first time after the
two delivery methods were republished separately. Here are a few
comments, none very major.

* Definitions: why do we use the definition of Event Transmitter to
add a normative statement about the Control Plane? And by the way,
if we want to mention the Control Plane, we'd better also define it.

* Similarly re: Control Plane in the definition of Event Receiver.

* Event Stream: dangling "and". Also, "Event Families" are not
defined/used anywhere else.

* NumericDate: I don't think we need to define it here.

* "Section 2.2 and 6.2 of [I-D.ietf-secevent-token]" should be
"Section 2.2 of the current document and 7.2 of
[I-D.ietf-secevent-token]".

* Sec. 2.2: the example request should include a Content-Length
header.

* 2.2: should we also allow for cases where some more detailed
validation takes place asynchronously, and so even though the
recipient returned a 202, it can still drop the SET? Example: if it
needs to look up a subject in a database.

* "A Client acting on behalf of an anonymous user (e.g., see next
section)." - I'm not sure what is referred to in the next section.

* Privacy Considerations: the first paragraph is not about privacy,
it is about authenticity/integrity.

Thanks,

Yaron

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 26 Jun 2018 14:23:20 -0700

Thanks Yaron,

I will take care of these issues and will try to submit a new version
before the July 2 deadline.

Marius

On Tue, Jun 26, 2018 at 2:05 PM Yaron Sheffer <[email-masked]> wrote:

> Dear authors, I just reread the draft, for the first time after the two
> delivery methods were republished separately. Here are a few comments, none
> very major.
>
> * Definitions: why do we use the definition of Event Transmitter to add a
> normative statement about the Control Plane? And by the way, if we want to
> mention the Control Plane, we'd better also define it.
> * "Section 2.2 and 6.2 of [I-D.ietf-secevent-token]" should be "Section
> 2.2 of the current document and 7.2 of [I-D.ietf-secevent-token]".
> * Sec. 2.2: the example request should include a Content-Length header.
> * 2.2: should we also allow for cases where some more detailed validation
> takes place asynchronously, and so even though the recipient returned a
> 202, it can still drop the SET? Example: if it needs to look up a subject
> in a database.
> * Privacy Considerations: the first paragraph is not about privacy, it is
> about authenticity/integrity.
>
> Thanks,
>     Yaron
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>