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

[Mike Jones <[e-mail]>]

Thanks for your review, Rob.  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: Robert Wilton via Datatracker <[e-mail]> 
Sent: Monday, June 22, 2020 9:54 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>; [e-mail]
Subject: Robert Wilton's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)

Robert Wilton 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:
----------------------------------------------------------------------

Hi,

I found this document easy to read.  A few minor nits:

1.2.  Definitions

   This specification utilizes the following terms defined in [RFC8417]:
   "Security Event Token (SET)", "SET Issuer", "SET Recipient", and
   "Event Payload".

   This specification utilizes terminology defined in [RFC8417], as well
   as the terms defined below:

This text could probably be simplified/made slightly less repetitive.

Mike> Thanks for the suggestion.  I removed the redundancy.

2.  SET Delivery

   Once the SET has been validated and persisted, the SET Recipient
   SHOULD immediately return a response indicating that the SET was
   successfully delivered.  The SET Recipient SHOULD NOT perform
   anything beyond the required validation steps prior to sending this
   response.  Any additional steps SHOULD be executed asynchronously
   from delivery, in order to minimize the expense and impact of SET
   delivery on the SET Transmitter.

Rather than "perform anything", perhaps "perform further processing of the SET"

Rather than "in order to minimize the expense and impact of SET delivery on the SET Transmitter." perhaps "to minimize the time the SET Transmitter is waiting for a response".

Mike> I applied both of these suggestions.

2.2.  Success Response

   Note that the purpose of the acknowledgement response is to let the
   SET Transmitter know that a SET has been delivered and the
   information no longer needs to be retained by the SET Transmitter.
   Before acknowledgement, SET Recipients SHOULD ensure they have
   validated received SETs and retained them in a manner appropriate to
   information retention requirements appropriate to the SET event types
   signaled.  The level and method of retention of SETs by SET
   Recipients is out of scope of this specification.

The normative behaviour of retaining SETs is already specified in section 2. 
It might be better to refer back to that previous paragraph rather than restating it here.

Mike> I refactored this to remove the redundancy.

7.  IANA Considerations

Section 7.1.1 lists the change controller as "IETF SecEvent Working Group", but the examples just list "IETF".  Presumably one of these needs to change?

Mike> Thanks.  It's not just "IETF".

Regards,
Rob

				Thanks again,
				-- Mike