open-standards/wai/extensions/carousel.md

WAI Extension: Carousel Schedule

Status: Draft. Registers the record wai.bearer.carousel: a publisher's signed schedule of when each object of a group passes on a bearer instance, and with which application-layer forward error correction. On a bearer with no return path a receiver cannot ask for what it missed: it holds an object only if the passes it heard carried enough encoding symbols. The schedule says what was planned to be sent, in a jwp-receipts claim of class schedule (jwp-receipts §2.4.16, §4 here), signed by the group's key beside the group receipt and the transmission claim of bearer-receipts §4. From it a verifier derives, for each object, when a receiver whose losses stay within a stated bound holds it (§6): the deadline a one-way bearer can promise, with the decoding failure the FEC code bounds. A receiver derives the passes it must listen to and when it may turn its radio off (§7). WAI defines no transport and no code: the codes are RaptorQ (RFC 6330) and Compact No-Code (RFC 5445), and the schedule declares their parameters. The reference implementation is the carousel module of wai-rs (feature carousel), with the class's body in claim_receipt::schedule; the corpus is live-conformance/carousel/, and its second implementation is live-conformance/carousel_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

Texts read for this revision: RFC 6330 (RaptorQ) with its verified erratum 5548, RFC 5445 (Compact No-Code) and RFC 5052 §9.1 (block partitioning). A clause number of one of them in this text is that RFC's. §11 also cites the IETF's IPR disclosures on RFC 5053, RFC 6330 and their drafts, read as the IETF datatracker shows them, and RFC 8179 §4.

1. Scope

In scope: the schedule claim (§4); how an object is divided into source blocks and symbols under each code (§5); when an object is held by a receiver whose losses stay within a bound, and the statements a verifier may check against it (§6); the passes a receiver listens to (§7).

Out of scope: encoding and decoding symbols, which are the codes' own (RFC 6330 §5, RFC 5445 §3); a transport, and how symbols are packed into packets; a model of a channel. Every statement here holds for every pattern of loss within the stated bound (§2). Whether losses on a channel are independent, and how often a bound is exceeded, is a judgement about that channel, which a relying party makes and a schedule does not carry. Nothing here states presentation, and nothing here states that any receiver heard anything: that is a reconciliation's (bearer-receipts §5).

Relationship to the core spec: wai.bearer.carousel is a record (SPEC §5): the schedule claim is a signed record a WAI tool emits and verifies. It names no payload format and is not dispatchable.

2. Terms

• Bearer instance, declaration, sink, relying party: as bearer-receipts §2. A declaration is a transmission claim that stands under bearer-receipts §6.2 step 4.
• Source block, source symbol, repair symbol, encoding symbol, ESI (encoding symbol ID): as RFC 6330 §2 and RFC 5052. An object is divided into source blocks; a block of K source symbols is sent as encoding symbols, each named by its ESI in that block.
• Pass: one transmission of encoding symbols of every source block of one object on a bearer instance, from its start to its end. An object's passes are numbered from 1.
• Instant: a count of milliseconds since 1970-01-01T00:00:00Z, leap seconds not counted, as channel-lineup writes one.
• Loss bound L: an integer from 0 to 999,999, in parts per million. A receiver is within L when, of the m encoding symbols of any one source block sent in any one pass, it fails to receive at most ⌊L · m / 1,000,000⌋, whichever they are. It is a bound on symbols: a relying party whose bound is stated on packets carrying several symbols each converts it.
• Overhead h: 0, 1 or 2, the encoding symbols beyond K′ a RaptorQ block is held at (§5.3).

3. Why a schedule beside the receipt

The group receipt signs its objects and names no bearer (bearer-receipts §3); the transmission claim names the bearer instance and attests that the publisher transmitted the group, which on a bearer with no return path says nothing about any receiver. Between the two is what decides whether a receiver that heard part of a transmission holds an object: how often each object passes, for how long, and with how many repair symbols. That is a plan, made before anything is sent, and it is a statement of the publisher's own:

• A relying party can hold a deadline to it. A publisher that offers an object to every receiver within a loss bound by a deadline makes a promise that the schedule either supports or does not (§6.4), checked with no receiver and no return path.
• A receiver can plan with it. It learns which passes add symbols it needs, and listens to those only (§7). On a receiver powered by a battery the radio is a large part of its energy.
• It changes no byte of what it schedules. The schedule names the group by its link hash and each object by its position and content hash, like a reconciliation. A group carried before this extension, or by a party that does not use it, verifies exactly as before.

The schedule attests a plan, not a transmission: that is the declaration's, and the schedule stands only beside one (§6.2). Neither attests that any receiver heard anything.

4. The schedule claim (class: "schedule")

A publisher that transmits a group over a multicast or unidirectional bearer instance MAY declare its schedule there in a schedule claim, one per bearer instance. Its subject_type is receipt and its subject the group receipt's link hash (jwp-receipts §3 step 3). It is signed by the key that signed the group. It attests that the publisher scheduled the passes it names, and nothing about what any sink received.

4.1 Body

member	type	meaning
bearer_id	absolute URI	The bearer instance (bearer-receipts §2): the bearer_id of the transmission claim it schedules.
objects	array	The objects scheduled, one entry each (below).
attests	string	MUST be "scheduled". Any string passes step 2; another value is refused at step 4.

Each entry of objects has exactly these members:

member	type	meaning
leaf_index	integer	The object's position in the group (jwp-receipts §2.2).
content_hash	32 B hex	The object's content hash (jwp-receipts §2.1): what a receiver that decodes the object checks it against.
fec	string	The code: raptorq (RFC 6330, FEC Encoding ID 6) or no-code (RFC 5445, FEC Encoding ID 0).
oti	object	The code's object transmission information, as §5 reads it. For raptorq, exactly transfer_length (F), symbol_size (T), source_blocks (Z), sub_blocks (N) and alignment (Al), RFC 6330 §3.3.2 and §3.3.3. For no-code, exactly transfer_length, symbol_size (the encoding symbol length) and max_block_length (the maximum source block length, in symbols), RFC 5445 §3.2.2.2. Each an integer.
repair	integer	The repair symbols of each source block sent in each pass, beyond its source symbols (§5.4).
esi	string	repeat: every pass sends the same ESIs. advance: each pass sends ESIs no earlier pass sent (§5.4).
first_ms	integer	The instant the first pass starts.
period_ms	integer	The time from one pass's start to the next's.
duration_ms	integer	The time each pass lasts.
count	integer	The number of passes.

fec and esi are read at jwp-receipts §3.1 step 2 against their enumerations, the members of oti against the code fec names, bearer_id as an absolute URI, and every integer as an unsigned 64-bit one (field_type).

4.2 Rules

Checked at jwp-receipts §3.1 step 4, in this order:

1. attests MUST be "scheduled" (schedule_not_scheduled).
2. objects has at least one entry, and its leaf_index values strictly increase (schedule_objects_malformed): one entry for each object scheduled, in group order.
3. Each entry in order, the first of these to fail:
   1. its oti is one its code admits, §5.1 or §5.2 (schedule_oti_invalid);
   2. its symbols are ones its code can name, §5.4 (schedule_symbols_invalid);
   3. its passes are well formed (schedule_passes_invalid): count and duration_ms are at least 1; with count at least 2, period_ms is at least duration_ms, so one pass of an object ends before its next starts; the last pass ends, first_ms + (count − 1) · period_ms + duration_ms, at or before 253,402,300,799,999 (9999-12-31T23:59:59.999Z); and the octets its passes send, bytes_sent (§5.4), are at most 2⁵³ − 1, the greatest integer a receipt states; each computed without overflow.

4.3 Against the group

Checked at jwp-receipts §3.1 step 6 against the group receipt the verifier holds, which has passed jwp-receipts §3 steps 1 and 2 and whose group_start is an RFC 3339 date-time (context_invalid otherwise; another receipt is context_mismatch), the object receipts it holds under that group, each of which has passed jwp-receipts §3 step 5, and the envelope bytes of those it holds. In order:

1. the group's link hash is the claim's subject (schedule_subject_mismatch);
2. the claim's signer_pubkey is the group's (schedule_signer_mismatch): only the publisher schedules its own transmission;
3. every leaf_index is less than the group's leaf_count (schedule_leaf_out_of_range);
4. no entry's first pass starts before the group does (schedule_before_group): ⌊first_ms / 1000⌋ is at least the seconds jwp-receipts §2.4.3 reads from group_start, its fraction dropped. Nothing can be sent before it exists;
5. for each entry whose object receipt the verifier holds, the receipt's content_hash is the entry's (schedule_content_mismatch); and for each whose envelope bytes it holds, their length is oti.transfer_length (schedule_length_mismatch).

A schedule checked without the group stops at step 5 and is not counted by §6.

4.4 Authority

Confirmed under jwp-receipts §7, a schedule claim needs the authority schedule, which is not pinned-only and is not delivery. An origin gives it to the keys that publish its groups, as it gives transmission.

5. Blocks and symbols

5.1 RaptorQ

The oti of a raptorq entry, F, T, Z, N and Al, is one RFC 6330 admits when:

• F is from 1 to 942,574,504,275 (§3.3.2 as erratum 5548 corrects it: 56,403 symbols of 65,535 octets in each of 255 blocks);
• T is from 1 to 65,535 and a multiple of Al, and Al from 1 to 255 (§3.3.2, §3.3.3, §4.2);
• Z is from 1 to 255, the range of its 8-bit field (§3.3.3: the parameters are positive);
• N is from 1 to T / Al, so each sub-block has a sub-symbol of at least Al octets (§4.4.1.2);
• with Kt = ⌈F / T⌉, Z is at most Kt, so no source block is empty, and ⌈Kt / Z⌉ is at most 56,403, K′_max (§4.4.1.2, §5.1.2).

The object is then divided as RFC 6330 §4.4.1.2 divides it: (KL, KS, ZL, ZS) = Partition[Kt, Z], where Partition[I, J] = (⌈I / J⌉, ⌊I / J⌋, I − ⌊I / J⌋ · J, J − (I − ⌊I / J⌋ · J)). The first ZL source blocks have KL source symbols each and the remaining ZS have KS. Each symbol is T octets; the last source symbol of the object is padded to T.

5.2 Compact No-Code

The oti of a no-code entry, with L its transfer_length, E its symbol_size and B its max_block_length, is one RFC 5445 admits when L is from 1 to 2⁴⁸ − 1, E from 1 to 65,535 and B from 1 to 2³² − 1 (RFC 5445 §3.2.2.2; an object of no octets has nothing to schedule), and the division of RFC 5052 §9.1 fits RFC 5445's 16-bit source block number and encoding symbol ID (§3.2.1):

• the object has Ts = ⌈L / E⌉ source symbols, in Nb = ⌈Ts / B⌉ source blocks;
• A_large = ⌈Ts / Nb⌉, A_small = ⌊Ts / Nb⌋ and I = Ts − A_small · Nb: the first I blocks have A_large source symbols and the others A_small;
• Nb is at most 65,536, and A_large at most 65,536.

Every symbol is E octets but the object's last, which holds what remains of L.

5.3 What a receiver needs

A block of K source symbols is held when a receiver can recover it:

• no-code: when it has received every one of its K source symbols. There are no repair symbols; a symbol missed is missed until a pass sends it again.
• raptorq: when it has received K′ + h distinct encoding symbols of the block, where K′ is the least value at least K in RFC 6330 Table 2 (§5.6; its column of K′ is restated in Appendix A). RFC 6330 §5.8 bounds the decoder's failure to recover a block of K′ source symbols from K′, K′ + 1 and K′ + 2 encoding symbols, chosen uniformly at random, at 1 in 100, 1 in 10,000 and 1 in 1,000,000 on average. A block of K < K′ symbols is padded to K′ with symbols the decoder knows (§5.3.1), so it may need fewer than K′ + h received; this text asks for the count §5.8 states its bound at, and no fewer.

An object is held when every one of its source blocks is.

5.4 The symbols a pass sends

Each pass sends, of each source block of K source symbols, m = K + repair encoding symbols:

• repeat: ESIs 0 to m − 1 in every pass;
• advance: in pass j, ESIs (j − 1) · m to j · m − 1. The first pass holds the source symbols (ESIs 0 to K − 1, RFC 6330 §4.4.2) and every later pass only repair symbols, none sent before.

An entry's symbols are ones its code can name (§4.2 rule 3.2) when:

• no-code: repair is 0 and esi is repeat. The code has no repair symbols, and an ESI past a block's last source symbol names nothing;
• raptorq: the greatest ESI sent fits the 24-bit field (RFC 6330 §3.2): with KL the larger block's K, KL + repair is at most 2²⁴ for repeat, and count · (KL + repair) at most 2²⁴ for advance, computed without overflow.

The octets an entry's passes send, bytes_sent, are count · Σ m · T over its source blocks for raptorq, and count · L for no-code, whose last symbol is short.

6. When an object is held

6.1 Inputs

The group receipt; the object receipts the verifier holds under it, each with its envelope bytes where it holds them; the transmission and schedule claims it holds about the group, each signer's in the order of its chain; a loss bound L; and an overhead h.

6.2 Steps

The loss bound and overhead are checked first: L above 999,999 is loss_bound_invalid, and h other than 0, 1 or 2 is overhead_invalid; neither derives anything. Then:

1. The group and its objects: bearer-receipts §6.2 steps 1 and 2.
2. The claims: each claim, in order, under jwp-receipts §3.1 steps 1 to 5, then step 6: a transmission claim by bearer-receipts §4.3 and a schedule by §4.3 here. A claim of another class is context_mismatch at step 6. A claim refused at any step takes no further part.
3. The declarations: bearer-receipts §6.2 step 4.
4. The schedules: the accepted schedule claims by bearer_id. Two with one bearer_id and different bodies set aside every schedule of that instance (schedule_contradicted): a publisher that changes its plan for one transmission has stated neither, and a relying party holds no promise that can change under it. Two with the same body are one. A schedule is then set aside at the first of these that holds: step 3 set aside the declarations of its bearer_id (bearer_contradicted); no declaration has its bearer_id (bearer_not_declared); its declaration's bearer is bidirectional (schedule_on_bidirectional), since a receiver with a path back asks for what it lacks and is not served by a plan. Otherwise it stands.
5. Availability, for each entry of each standing schedule, by §6.3.

6.3 Availability

For an entry, pass j ends at the instant first_ms + (j − 1) · period_ms + duration_ms. For each source block of K source symbols, with m = K + repair and x = ⌊L · m / 1,000,000⌋ the most a receiver within L misses of it in one pass, the first pass after which a receiver within L holds the block is, under §5.3:

• raptorq, advance: the least j from 1 to count with j · (m − x) ≥ K′ + h. Every pass adds m − x symbols none before it sent.
• raptorq, repeat: 1 if m − x ≥ K′ + h, and none otherwise. A later pass sends the same ESIs, and the ones a receiver missed may be missed again: within L, nothing it adds is certain.
• no-code: 1 if x is 0, and none otherwise, for the same reason.

The object is available at the end of the greatest of its blocks' passes, or is not available within the schedule if any block has none. A verifier reports for each entry its available_ms (or null), the pass, bytes_sent (§5.4), and, for raptorq, the RFC 6330 §5.8 bound at h as failure_one_in (100, 10,000 or 1,000,000); for no-code it is null, a block held being recovered exactly.

6.4 Statements offered about an object or a group

A verifier MAY be asked to check a statement, on a bearer instance, for a loss bound L and an overhead h:

• object i is held by t: holds when a standing schedule of the instance has an entry for object i that is available at an instant at or before t. It is refused when no standing schedule of the instance has one (object_not_scheduled), when it is not available within the schedule (availability_not_within_schedule), and when it is available after t (availability_after_deadline).
• the group is held by t: holds when the statement holds for every object of the group, 0 to leaf_count − 1, and is refused with the first object's reason otherwise.

A statement that holds says what the publisher planned: a receiver within L, hearing every pass the schedule names, holds the object by t, but for a decoding failure no more likely than failure_one_in states. It does not say the passes were sent (the declaration's) or heard (a reconciliation's).

A publisher's own deadline for an object is its timeliness claim's by_ms (timeliness §4.1); held by it, the statement is the publisher's plan against its own deadline.

7. The passes a receiver listens to

A receiver that holds a standing schedule's entry, the instant t it is at, its loss bound L, the overhead h it decodes at, and, for each source block, the number n of distinct encoding symbols of it that it holds (for no-code, of its source symbols), derives the passes to listen to. The loss bound and overhead are checked as §6.2 checks them, and a holding that does not give one number for each source block of the object, in the order §5.1 and §5.2 divide it into them, or that holds more source symbols of a no-code block than it has, is holding_invalid. Only passes that start at or after t count: a pass under way at t has sent symbols the receiver did not hear. A pass adds, to a block not held, with m and x as §6.3:

• raptorq, advance: m − x, none of them sent before;
• raptorq, repeat and no-code: max(0, m − n − x): of the m − n ESIs it lacks, x may be the ones it misses again.

The passes are taken in order of their start. While some block is not held, the next pass is listened to if it adds to a block not held, each such block's n growing by what it adds; the first pass that adds to none ends the plan. The plan is the passes listened to, each with its start and end; complete_ms, the instant the object is held: t when it already is, the last pass's end when the passes listened to suffice, and null otherwise; and listen_ms, the sum of their durations: the time the receiver's radio must be on. Outside those passes it MAY be off. Under repeat and no-code at most one pass adds anything certain within L, since after it a block lacks only symbols the receiver may miss again: a receiver that one pass does not complete is not certain to be held after any number, and keeps listening, if it does, on its own judgement of its channel.

8. Mappings

A bearer that carries files with FEC states the same parameters in its own description of each file, for its receivers: on FLUTE (RFC 6726) and the bearers built on it, the FEC Object Transmission Information of each file in the file delivery table. A schedule restates them, signed by the publisher, beside the group's receipts, so a relying party with no access to the bearer can check a promise (§6.4) and a receiver can plan before it tunes (§7). A sink that holds both compares them; a difference is the bearer's, and the sink reports it rather than choosing one. The bearer's own repetition (its carousel of descriptions and files) is the schedule's passes: a pass is one transmission of the object's symbols, whatever the bearer calls it.

9. Reasons

The codes this extension adds, each with where it is raised:

reason	raised at
schedule_not_scheduled	§4.2 rule 1
schedule_objects_malformed	§4.2 rule 2
schedule_oti_invalid	§4.2 rule 3.1
schedule_symbols_invalid	§4.2 rule 3.2
schedule_passes_invalid	§4.2 rule 3.3
schedule_subject_mismatch	§4.3 step 1
schedule_signer_mismatch	§4.3 step 2
schedule_leaf_out_of_range	§4.3 step 3
schedule_before_group	§4.3 step 4
schedule_content_mismatch	§4.3 step 5
schedule_length_mismatch	§4.3 step 5
schedule_contradicted	§6.2 step 4
schedule_on_bidirectional	§6.2 step 4
loss_bound_invalid	§6.2, §7
overhead_invalid	§6.2, §7
holding_invalid	§7
object_not_scheduled	§6.4
availability_not_within_schedule	§6.4
availability_after_deadline	§6.4

A schedule also raises bearer_contradicted and bearer_not_declared (bearer-receipts §10) at §6.2 step 4; a group or object the codes of jwp-receipts §3.3; and a claim every code of jwp-receipts §3.1 steps 1 to 5 and those of step 6 named in §4.3 and bearer-receipts §4.3.

10. Conformance

live-conformance/carousel/ holds the corpus, written from fixed seeds by wai_carousel_vectors gen as vectors.json. It has:

• Availability: RaptorQ objects of one and of several source blocks of two sizes, under advance and repeat, at loss bounds of zero and above, reaching a later pass, the last pass, and none; at each overhead; a Compact No-Code object available at the first pass with no loss and at none with any; a group of several objects; the same object simulcast on two instances with different schedules.
• Statements: an object and a group held by a deadline, after it, not within the schedule, and not scheduled.
• Plans: a receiver tuning in before the first pass, during one, between passes, holding part of an object, holding all of it, and one under repeat that one pass does not complete.
• Negative controls, one for each reason of §9 that a claim or a verdict raises, and the bounds of §5.1, §5.2 and §5.4 on both sides.

A conforming verifier gives every case the outcome, the reason and everything else the corpus states. wai_carousel_vectors verify and the test tests/carousel.rs check that the file regenerates byte for byte, that wai-rs gives every case its outcome, that every reason of §9 appears, that §9 lists exactly the reference's codes, and that Appendix A is the reference's table. Against an independent implementation of RFC 6330, the test also requires the reference's K′ and Partition[] to agree for every block size, and decodes each RaptorQ object a case holds available at a pass: it encodes the object under the entry's parameters, drops in each pass the first ⌊L · m / 1,000,000⌋ symbols of each block (in the first pass, source symbols, so the decoder must decode), and requires the object back from what is left by that pass's end. live-conformance/carousel_verify.py is the second implementation, written from this text: it shares no code with wai-rs; it verifies groups and objects with the JWP corpus's second implementation (jwp-conformance/jwp_verify.py), and claims through steps 1–5 with the claim corpus's (claim-conformance/claim_verify.py), whose step 4 holds §4.2 with §5.1, §5.2 and §5.4; it reads Appendix A and §9 from this text, writes §4.3, §5.3, §6 and §7 itself, mutates copies of the corpus and requires every copy to fail, and drops each of its own checks in turn and requires the corpus to catch the weakened verifier.

11. Patents

The IETF holds disclosures of patents claimed to read on RaptorQ, all from one holder: #1292, #1511 and #1553 on the drafts of RFC 6330, #1958 on RFC 6330, and #2554 (19 March 2015), which updates #1958 and has not itself been updated. Its licensing declaration is written out in the holder's words, not chosen from the disclosure form's options, and gives two terms, by the product that implements the code:

• a device that fully implements the specification and implements a wireless wide-area standard (the disclosure's example is a UMTS handset or infrastructure equipment): the holder offers a licence as part of its established terms for such devices, with no royalty beyond its standard rate for them. The class is royalty-bearing, within the licence the device already needs;
• a device that fully implements the specification and implements no wireless wide-area standard: the holder will not assert the claims against anyone who makes, uses, sells, imports or offers it, solely for that implementation; it keeps the right to assert them against a party that asserts a patent against its or its affiliates' products, and against a product or part that does not fully implement the specification. The class is royalty-free non-assertion, conditional on full implementation and suspended for a party that asserts.

Raptor (RFC 5053), which this revision does not name (§4.1), has disclosures from the same holder and an earlier one: #615, #618, #702 and #734 on its drafts; #1185 (8 September 2009) on RFC 5053, which declared a reasonable and non-discriminatory licence with possible royalty or fee; and #1289, #1508, #1744 and #1957 (6 February 2013), each updating the one before. #1957 has not been updated, and gives the same two terms as #2554. The holder's general licence statement, #1176 (20 July 2009), relates to no one document: it offers a non-exclusive licence on reasonable and non-discriminatory terms, on the basis of reciprocity, for the holder's submissions that an IETF standard incorporates.

No disclosure relates to RFC 5445 or its draft, nor to RFC 5052, whose division §5.2 applies. The IETF takes no position on the validity or scope of any disclosed claim (RFC 8179 §4).

Therefore:

• no-code is the default. Neither RaptorQ nor Raptor is royalty-free for every implementer: whether a royalty is due turns on the product, which a schedule does not state. Under SPEC §5 a capability that is not royalty-free is never a default, and the same holds here: a tool that writes schedules writes no-code unless it is set to write raptorq.
• The reference implementation encodes and decodes no symbol (§1). Its carousel module computes, from the parameters an entry states, the division of §5 and the counts of §6 and §7. Its test decodes RaptorQ with an independent implementation of RFC 6330 that is a development dependency of wai-rs, which no build of the library carries.
• Whether a product that encodes or decodes RaptorQ or Raptor symbols needs a licence under these disclosures is a decision for its distributor.

12. Security and privacy considerations

• A schedule is the publisher's word. Nothing checks that the passes were sent as planned; a declaration attests transmission and no more, and a relying party that needs to know what receivers held counts reconciliations (bearer-receipts §6). A schedule that promises more than was sent is a false statement signed by the group's key, and is evidence of it.
• A loss bound is the relying party's. Every statement holds for every pattern of loss within it (§2). A channel that exceeds it, in a fade or under interference, voids nothing in the schedule and nothing here predicts how often that happens.
• It discloses the plan, not the audience. A schedule names objects, times and code parameters, which the bearer's own file descriptions already carry to every receiver. A receiver that plans with it (§7) sends nothing, and a unidirectional bearer's property that the source learns nothing of its receivers (unidirectional-delivery §2) is kept.
• Bounded work. An entry's arithmetic is a few products per source block, and an object has at most 255 RaptorQ blocks of two sizes or Compact No-Code blocks of two sizes; a schedule's cost is linear in its entries, whatever the passes' count.

Appendix A. The values of K′

The column K′ of RFC 6330 Table 2 (§5.6), in increasing order, restated so that §5.3 can be applied from this text. The other columns of that table are the code's, and nothing here uses them.

10, 12, 18, 20, 26, 30, 32, 36, 42, 46, 48, 49, 55, 60, 62, 69,
75, 84, 88, 91, 95, 97, 101, 114, 119, 125, 127, 138, 140, 149, 153, 160,
166, 168, 179, 181, 185, 187, 200, 213, 217, 225, 236, 242, 248, 257, 263, 269,
280, 295, 301, 305, 324, 337, 341, 347, 355, 362, 368, 372, 380, 385, 393, 405,
418, 428, 434, 447, 453, 466, 478, 486, 491, 497, 511, 526, 532, 542, 549, 557,
563, 573, 580, 588, 594, 600, 606, 619, 633, 640, 648, 666, 675, 685, 693, 703,
718, 728, 736, 747, 759, 778, 792, 802, 811, 821, 835, 845, 860, 870, 891, 903,
913, 926, 938, 950, 963, 977, 989, 1002, 1020, 1032, 1050, 1074, 1085, 1099, 1111, 1136,
1152, 1169, 1183, 1205, 1220, 1236, 1255, 1269, 1285, 1306, 1347, 1361, 1389, 1404, 1420, 1436,
1461, 1477, 1502, 1522, 1539, 1561, 1579, 1600, 1616, 1649, 1673, 1698, 1716, 1734, 1759, 1777,
1800, 1824, 1844, 1863, 1887, 1906, 1926, 1954, 1979, 2005, 2040, 2070, 2103, 2125, 2152, 2195,
2217, 2247, 2278, 2315, 2339, 2367, 2392, 2416, 2447, 2473, 2502, 2528, 2565, 2601, 2640, 2668,
2701, 2737, 2772, 2802, 2831, 2875, 2906, 2938, 2979, 3015, 3056, 3101, 3151, 3186, 3224, 3265,
3299, 3344, 3387, 3423, 3466, 3502, 3539, 3579, 3616, 3658, 3697, 3751, 3792, 3840, 3883, 3924,
3970, 4015, 4069, 4112, 4165, 4207, 4252, 4318, 4365, 4418, 4468, 4513, 4567, 4626, 4681, 4731,
4780, 4838, 4901, 4954, 5008, 5063, 5116, 5172, 5225, 5279, 5334, 5391, 5449, 5506, 5566, 5637,
5694, 5763, 5823, 5896, 5975, 6039, 6102, 6169, 6233, 6296, 6363, 6427, 6518, 6589, 6655, 6730,
6799, 6878, 6956, 7033, 7108, 7185, 7281, 7360, 7445, 7520, 7596, 7675, 7770, 7855, 7935, 8030,
8111, 8194, 8290, 8377, 8474, 8559, 8654, 8744, 8837, 8928, 9019, 9111, 9206, 9303, 9400, 9497,
9601, 9708, 9813, 9916, 10017, 10120, 10241, 10351, 10458, 10567, 10676, 10787, 10899, 11015, 11130, 11245,
11358, 11475, 11590, 11711, 11829, 11956, 12087, 12208, 12333, 12460, 12593, 12726, 12857, 13002, 13143, 13284,
13417, 13558, 13695, 13833, 13974, 14115, 14272, 14415, 14560, 14713, 14862, 15011, 15170, 15325, 15496, 15651,
15808, 15977, 16161, 16336, 16505, 16674, 16851, 17024, 17195, 17376, 17559, 17742, 17929, 18116, 18309, 18503,
18694, 18909, 19126, 19325, 19539, 19740, 19939, 20152, 20355, 20564, 20778, 20988, 21199, 21412, 21629, 21852,
22073, 22301, 22536, 22779, 23010, 23252, 23491, 23730, 23971, 24215, 24476, 24721, 24976, 25230, 25493, 25756,
26022, 26291, 26566, 26838, 27111, 27392, 27682, 27959, 28248, 28548, 28845, 29138, 29434, 29731, 30037, 30346,
30654, 30974, 31285, 31605, 31948, 32272, 32601, 32932, 33282, 33623, 33961, 34302, 34654, 35031, 35395, 35750,
36112, 36479, 36849, 37227, 37606, 37992, 38385, 38787, 39176, 39576, 39980, 40398, 40816, 41226, 41641, 42067,
42490, 42916, 43388, 43840, 44279, 44729, 45183, 45638, 46104, 46574, 47047, 47523, 48007, 48489, 48976, 49470,
49978, 50511, 51017, 51530, 52062, 52586, 53114, 53650, 54188, 54735, 55289, 55843, 56403