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

["Richard Backman, Annabelle" <[e-mail]>]

We've published draft-ietf-secevent-http-push-14 addressing this 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?

The SET Transmitter may not know whether or not a SET was delivered successfully (e.g., if a network outage prevented the SET Transmitter from receiving the HTTP response). We've revised the last three paragraphs of §2 to clarify this and that SET Recipients are required to tolerate re-transmission of successfully delivered SETs. We also added text to §4 explaining these circumstances.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 6/24/20, 9:42 PM, "Id-event on behalf of Mike Jones" <[e-mail] on behalf of Michael.Jones=[e-mail]> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



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

_______________________________________________
Id-event mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/id-event