Stephen Farrell's No Objection on draft-ietf-httpbis-alt-svc-12: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-alt-svc-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-httpbis-alt-svc/



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


- If TLS1.3 continues to have 0rtt replayable early-data,
could that interact badly with Alt-Svc? Or what about
false-start? For example, if such a combination meant that an
otherwise functional replay detection scheme would fail to
spot a replay that would be bad. This is not a DISCUSS, as
neither TLS1.3 nor false-start are formally "done" so blocking
this for that reason would be "odd";-) However, both are
implemented or will be, so I would love to chat about it and
that might lead to some new security considerations text, here
or in a TLS document.

- Does this still all work for opportunistic security for
HTTP? If not, why not? Note: I'm not asking if the WG have
reached consensus on oppo, rather I'd like to be reassured
that if they do, this will still work for that. I think that's
all ok, though, right?

- section 3: with "clear" you say alternatives are to be
invalidated. Does that mean anything about cached resources? I
assume not, but just checking.

- section 5: I wondered why you didn't include the ALPN
identifier here?

- 9.2: What does "might also choose" mean and which "other
requirements" have you in mind? That's very vague.

- 9.5: What are you telling me with the last para?