Adam Roach's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-replay-03: Yes

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-httpbis-replay/



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

Thanks to everyone who worked on this document. I appreciate its concision and
clarity.

I have one comment that is either quite important or a misunderstanding on my
part, followed by a couple of very minor editorial nits.

---------------------------------------------------------------------------

§5.2:

>  In all cases, an intermediary can forward a 425 (Too Early) status
>  code.  Intermediaries MUST forward a 425 (Too Early) status code if
>  the request that it received and forwarded contained an "Early-Data"
>  header field.  Otherwise, an intermediary that receives a request in
>  early data MAY automatically retry that request in response to a 425
>  (Too Early) status code, but it MUST wait for the TLS handshake to
>  complete on the connection where it received the request.

This seems correct but incomplete.

I believe that we also want to (MUST-level) require the forwarding of the 425
in the case in which an intermediary receives a request from a client in early
data (i.e., no "Early-Data" header field), forwards it towards the origin
(with an "Early-Data" header field), and then receives a 425 response. I
suspect the intention here was to cover that case in the "MUST" above, but
it's not what the text actually says.

---------------------------------------------------------------------------

Presumably, the "Note to Readers" section immediately following the abstract
is to be removed prior to publication?  Please either remove it or add a note
that the RFC editor should remove it.

---------------------------------------------------------------------------

§4:

>  If the server rejects early data at the TLS layer, a client MUST
>  start sending again as though the connection was new.

nit: s/was new/were new/