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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Sat, 20 Jun 2020 12:05:36 -0700

Murray Kucherawy 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 2:
* "SET parsing and issuer and ..." -- s/parsing and/parsing,/
* I'm struggling a bit with the SHOULD and SHOULD NOT in the final paragraph. 
When would you legitimately re-transmit a delivered SET, or not delay
re-transmission after a failure?

Section 2.1:
OLD:
   ... request to an HTTP endpoint using TLS provided by the SET Recipient.
NEW:
   ... request to a TLS-enabled HTTP endpoint provided by the SET Recipient.

* This section makes several references to "header" that I think should be
"header field".

Section 2.3:
* Same issue with the SHOULD in the first paragraph: When would you not use an
appropriate HTTP response code? * I think the "MAY" in the "description" bullet
is superfluous, since you're describing interoperability with a human at this
point. * Same issue with "header" here, with three instances in this section. *
I suggest that the example figures in this section should be indented.  One of
them is actually outdented. * "example non-normative" should be "non-normative
example", with three instances in this section.

Section 2.4:
* The table here is effectively a copy of the table in Section 7.1.2.  Could we
just replace this section with a forward reference?

Section 4:
* "... always retry failed transmissions, however, it should ..." -- "however"
should start a new sentence, or at least the first comma should be a semi-colon
* More generally, I wonder if leaving the "retryability" (I wish that was a
word) to the discretion of an implementation, which feels mushy, could be
improved.  In SMTP and various other protocols there's an indication, as part
of the reply, that tells the client whether a failure might succeed later on a
retry (say, a local resource limitation that might clear) versus one that will
presumably never succeed (no such user here).  The DNS makes the same
distinction.  For example, including in the registry a column indicating
whether a response is indicating a temporary or permanent condition might be
useful, or it could be a formalized part of the JSON reply.

Section 5.5:
* "... systems that the SET Recipient forwards the SET onto ..." -- suggest
"... systems to which the SET Recipient forwards the SET ..."

Section 6:
* The variable use of "should" and "SHOULD" here made me look a bit sideways at
this section.  They all "feel" the same, so the variance seems odd.

Section 7.1.1:
* For "Error Code", this set of restrictions allows me to register a code
called "_".  Do you want more restrictions here? * "For error codes registered
by the IETF or its working groups, list "IETF SecEvent Working Group"." -- What
if it was some other working group?

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Jun 2020 22:07:12 -0700

Hi Murray,

Just my thoughts on a subset of the topics; the authors will need to
respond for most of them.

> https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/

I see that Adam Roach's legacy lives on :)

> appropriate HTTP response code? * I think the "MAY" in the "description" bullet

I think this is "you SHOULD respond", not "you SHOULD use an appropriate
error code".  I agree about the "MAY".

> this section.  They all "feel" the same, so the variance seems odd.

I think "SHOULD consider" is not terribly enforcable -- what does it mean
to "consider".  OTOH, "attempt to deliver" seems more concrete, so "SHOULD
attempt to deliver" seems to be at least somewhat enforcable.

> called "_".  Do you want more restrictions here? * "For error codes registered

I think the DEs would look at you pretty funny about "_"...

> if it was some other working group?

Good point.

Thanks for the review!

-Ben

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jun 2020 16:44:54 -0700

> I see that Adam Roach's legacy lives on :)

It was beaten into me years ago and now you all get to pay for it.  :-)

> error code".  I agree about the "MAY".

You may be right but then it's not clear to which part of the
requirement the SHOULD binds.  Either way, the paragraph is worth a
second look.

> attempt to deliver" seems to be at least somewhat enforcable.

Yes, that's also something to be reviewed.

> I think the DEs would look at you pretty funny about "_"...

True, but absent any guidance to the DE about what names are
acceptable, a future DE might think "Well, it's not disallowed by the
defining RFC, so..."

-MSK