Yes. Do you have an alternate suggestion? On Mon, Jan 11, 2021 at 5:54 PM Christian Huitema <[email protected]> wrote:
> > On 1/11/2021 5:22 PM, Martin Duke wrote: > > Perhaps I should make some edits for clarity! > > On Mon, Jan 11, 2021, 16:52 Christian Huitema <[email protected]> wrote: > >> I am looking at the text of section 4.2, and I am not sure how I would >> implement that. What should be the value of the config rotation bits in CID >> created by the server? >> > Any config includes the corresponding CR bits, and when generating the CID > it would use those bits. > > The confusing part is that, for this algorithm, a usable SID has to be > extracted from any CID, hence all the weird stuff about CIDs with undefined > configs. > > Aside from that, it's like PCID: any server-generated CID uses the CR bits > in the config, optional length encoding, SID, server-use octets. > > Should the 6 other bits in the first octet be set to a CID Len or to a >> random value? >> > It depends on the rest of the config, as with the other algorithms. > >> Issss the timer set when the server ID is first added to the table, or is >> the timer reset each time a packet is received with that CID? In the latter >> case, is it reset when any packet is received, or only when a "first >> initial" packet is received? >> > When any packet is received with that SID (not CID), the expiration is > refreshed. > > OK. So we can have the following: > > 1) Server learns of Server-ID = X. > > 2) Server creates new CID with that server ID, uses it to complete > handshake. > > 3) Client maintains a long running connection with that CID. > > 4) Server keeps receiving messages with CID pointing to server-ID = X > > 5) server-ID=X never expires. > > Is that by design? > > -- Christian Huitema > > >
