This is not how I read the draft at all. There are two separate paths, no? client->server and server->client?
4.5.2: This has no direct effect on reverse paths from this endpoint to the peer. If the peer wants to direct the endpoint to abandon such paths, it should send PATH_STATUS(abandon) frames for the relevant paths. So IIUC PATH_STATUS refers to the peer's CID/identifier, and RETIRE_CONNECTION_ID refers to the sender's CID/identifier, so both are necessary to tear down both ends? On Wed, Dec 16, 2020 at 2:15 PM Christian Huitema <[email protected]> wrote: > > On 12/16/2020 1:39 PM, Martin Duke wrote: > > Thanks for this draft! I like the way it's going. > > > > I'm not sure I like the repurposing of RETIRE_CONNECTION_ID to close a > > path. There are other valid reasons to retire a path -- for instance, > > the sequence number is low relative to the other active ones, and the > > intermediate numbers are requiring extra state. RETIRE_CONNECTION_ID > > is useful to force the peer to use a new CID for the path. > > We had a bit of discussion about that. The RETIRE_CONNECTION_ID is not > meant to trigger a peer's action, except for freeing the resource > associated with the connection ID that is being retired. The PATH_STATUS > frame may be used to request a peer to abandon a path. > > -- Christian Huitema > >
