Change:
Address validation can use 3*PTO, just taking the maximum of the old and new path PTO. The idea of initial timeout is easily replaced in recovery by instead describing the effect on the PTO. The net effect is the same, except that new paths often have to include the maximum ACK delay, which this doesn't incorporate.
A quick look in the reference did not show what units of time you are using in the protocol - maybe I missed it?
is set to 333ms. Not sure why a max between two values needs to define the unit in the first place though.
is not defined in -transport, and Stewart was (probably) only reviewing the document in isolation.
NAME a max needs to ensure both values use the same units. But provided that they do, I agree.
Maybe it's easier to say that these are all physical quantities, or numbers with units. In the specification, we use seconds, milliseconds, microseconds. That's fine, because we know how to align the units when we make calculations (e.g., max).
PR proposes removing the text in question. Of course, it doesn't matter what time units are in use in this case. I'm fairly confident that where units matter (i.e., we base the value on a constant), the units are explicit. Here, the units are part of the definition of the variables.
As Martin points out, the offending text was removed. Not seeing anything to be done here , so I'm closing the issue.
says "initial timeout (that is, )". But I don't think that we have this initial timeout concept in recovery any more; we . Should this just be now? The result is that the is meaningless as the PTO is when initialized. Or is this the PTO on the pre-existing path?
I think this is the case. Notice "current." Therefore I belive that the formula should be .
Changing 2kInitialRtt to 3kInitialRtt and 6kInitialRtt to 9kInitialRtt seems like the simplest fix since we don't define an initial_PTO variable anywhere in the documents.
I assume that the choice between and is purely editorial. Either works for me.
I prefer with some changes that I've noted on the PR.
I think this is correct. LGTM, but waiting for NAME to take a look.

Discussion:
Resumed connections over the same network MAY use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  When no previous RTT is available, the initial RTT <del> SHOULD be set to 333ms, resulting in a 1 second initial timeout, as recommended in RFC6298. </del> <ins> SHOULD be set to 333ms.  This results in handshakes starting with a PTO of 1 second, as recommended for TCP's initial retransmission timeout; see Section 2 of RFC6298. </ins> A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in

Endpoints SHOULD abandon path validation based on a timer.  When setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original.  A value of <del> three times the larger of the current Probe Timeout (PTO) or the initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is: </del> <ins> three times the larger of the current Probe Timeout (PTO) or the PTO for the new path (that is, using kInitialRtt as defined in QUIC- RECOVERY) is RECOMMENDED. </ins> This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE