From c9aeace20f8fb0372fd7f2ff8cc0065c9a585d41 Mon Sep 17 00:00:00 2001 From: Maxim Raznatovski Date: Tue, 6 Oct 2026 10:16:36 +0200 Subject: [PATCH 1/2] docs: state that the pairing round count does not reset mid-attempt --- README.md | 2 +- pairing.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 91c2de0..8bf9bad 100644 --- a/README.md +++ b/README.md @@ -984,7 +984,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`. -After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. +After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. Only that action and a verified `server_kc` reset the count: an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for. diff --git a/pairing.md b/pairing.md index c8c8df9..a5e797d 100644 --- a/pairing.md +++ b/pairing.md @@ -182,7 +182,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`. -After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. +After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. Only that action and a verified `server_kc` reset the count: an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for. From 867badeacdb581644985462fa2954e29a049e0a1 Mon Sep 17 00:00:00 2001 From: Maxim Raznatovski Date: Fri, 23 Oct 2026 05:54:12 +0200 Subject: [PATCH 2/2] docs: say which operator actions reset the pairing round count --- README.md | 2 +- pairing.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 8bf9bad..c4494bd 100644 --- a/README.md +++ b/README.md @@ -984,7 +984,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`. -After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. Only that action and a verified `server_kc` reset the count: an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. +After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. Only a verified `server_kc` and an operator action that releases held-back attempts reset the count: the end of a cooldown or an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for. diff --git a/pairing.md b/pairing.md index a5e797d..ef7e3e0 100644 --- a/pairing.md +++ b/pairing.md @@ -182,7 +182,7 @@ A failed key confirmation results in [`pair/abort`](#client--server-pairabort) w An attempt runs **rounds** against the same pairing code. A round begins with [`server/pair-init`](#server--client-serverpair-init) and ends with the client's verification of `server_kc` from [`server/pair-confirm`](#server--client-serverpair-confirm), or with the attempt. Within it the client emits the code, the operator enters it, and a separate CPace run - fresh scalars, its own `sid` - follows. On a verified `server_kc` the client continues with [`client/pair-confirm`](#client--server-clientpair-confirm). On failure the client either sends [`client/pair-retry`](#client--server-clientpair-retry), asking for another round, or ends the attempt with [`pair/abort`](#client--server-pairabort) reason `pairing_code_mismatch`. The client SHOULD retry, and MUST abort instead at the round limit. A retry keeps the attempt, its pairing code, and its running [attempt timeout](#entering-and-leaving-pairing) in place; the server begins the next round with a new `server/pair-init`. -After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action, which also resets the count. Only that action and a verified `server_kc` reset the count: an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. +After 20 rounds since its last verified `server_kc` - the **round limit** - the client MUST abort rather than retry and hold attempts back until a deliberate, manufacturer-defined operator action. A client MAY hold attempts back earlier - by a cooldown or by an operator action, including from the first attempt - and MAY likewise abort rather than retry short of the limit. Only a verified `server_kc` and an operator action that releases held-back attempts reset the count: the end of a cooldown or an operator action during an attempt does not. The count is not partitioned by `server_id` or source address. The limit is not an error state - the method stays offered - and while it holds an attempt back the client sends [`client/pair-pending`](#client--server-clientpair-pending), optionally saying in `message` what it waits for.