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

[Mike Jones <[e-mail]>]

Thanks for your review, Murray.  https://tools.ietf.org/html/draft-ietf-secevent-http-push-13 is intended to address your comments.  Detailed replies are inline, prefixed by "Mike>".

-----Original Message-----
From: Murray Kucherawy via Datatracker <[e-mail]> 
Sent: Saturday, June 20, 2020 12:06 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>
Subject: Murray Kucherawy's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)

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,/

Mike> Thanks - fixed.

* 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?

Mike> Another place I reworded to eliminate the problematic SHOULD...

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.

Mike> Thanks - I used this wording uniformly across both drafts.

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

Mike>  Thanks - I applied this across both drafts.

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.

Mike> Reworded again

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?

Mike> The table is much more human-readable than the IANA Considerations section.  Therefore, I opted to leave them both.

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

Mike> Done

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

Mike> The current text tries to say that you should retry when the error is likely to be transient and otherwise not.  The error codes are fairly coarse-grained, so it's not likely that particular error codes are always retryable or not retryable.

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

Mike> Done

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.

Mike> They're now all "should".

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?

Mike> I added some instructions to the Designated Experts in response to Barry's review.  But didn't want to try legislate everything about the nature of the identifiers.  I trust the experts to use common sense.

				Thanks again,
				-- Mike