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

[Mike Jones <[e-mail]>]

I responded to most of Murray's comments directly but I forgot to add that I changed "IETF SecEvent Working Group" to simply "IETF".  Several other reviewers also called this out.

				-- Mike

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

Hi Murray,

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

On Sat, Jun 20, 2020 at 12:05:36PM -0700, Murray Kucherawy via Datatracker wrote:
> 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".

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

> 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

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

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

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.

> 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

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

> by the IETF or its working groups, list "IETF SecEvent Working 
> Group"." -- What if it was some other working group?

Good point.

Thanks for the review!

-Ben