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

[Mike Jones <[e-mail]>]

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

-----Original Message-----
From: Murray Kucherawy via Datatracker <[e-mail]> 
Sent: Wednesday, June 17, 2020 7:58 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>
Subject: [EXTERNAL] Murray Kucherawy's No Objection on draft-ietf-secevent-http-poll-11: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-secevent-http-poll-11: 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-poll/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A couple of questions arise for me about the use of requirements language:

Section 2.1:
* Under what circumstances would you not follow the advice of that SHOULD?

Mike> I reworded this to eliminate the SHOULD, as I did a number of places in both drafts.

Section 2.2:
* "... the oldest SETs available SHOULD be returned first." -- why is that only a SHOULD?

Mike> Conferring with Annabelle, we instead made it clear that it's to the sender what order to send the SETs.  While FIFO may be the default, priority sorting of SETs should not be excluded.  We want this to work well across different kinds of use cases.

Section 2.4:
* "... SHOULD parse and validate received SETs to meet its own requirements ..." -- when would you not do this?

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

And a nit:

Section 2.2:
* "An OPTIONAL JSON integer value ..." -- JSON defines "number", not "integer"; I understand what you mean, but that distinction has drawn complaints on previous documents.

Mike> I deleted "JSON".

				Thanks again,
				-- Mike