Example for PATH_ABANDON does not follow spec recommendation

[gloinul]

Section 5.2: Client Server (client tells server to abandon a path with Path ID 1) 1-RTT[X]: DCID=S1 PATH_ABANDON[Path ID=1]-> (server tells client to abandon a path) <-1-RTT[Y]: DCID=C1 PATH_ABANDON[Path ID=1], MP_ACK[PATH ID=1, PN=X] 1-RTT[U]: DCID=S2 MP_ACK[Path ID=1, PN=Y] ->

Shouldn't client send the PATH_ABANDON on DCID=S0 or S2 and not over the path it closes. The same for the server. The spec receommends against sending them over the path being abandoned.

[Yanmei-Liu]

In Section 3.3 which said:

PATH_ABANDON frames can be sent on any path, not only the path that is intended to be closed. Thus, a path can be abandoned even if connectivity on that path is already broken. Respectively, if there is still an active path, it is RECOMMENDED to send the PATH_ABANDON frames on another path.

I think the current draft doesn't limit that PATH_ABANDON can only be sent on another path. It's recommended that if the corresponding path is considered broken(black hole or high loss ratio), endpoints could choose to send the PATH_ABANDON frames on another path.

[gloinul]

Ok, in that case I think the quoted text from Section 3.3 needs to be changed. I at least interpret that the recommendation is applying in general, not only to cases where one think the path being abandon is broken or poorly functioning. So I would suggest rewording this, and use another word than "respectively" also.

[mirjak]

I think that should be fine now with PR #420 as discussed in issue #410. Closing this issue, respectively ;-)