Consensus methods 15 through 17 are undocumented

Looks like dir auths recently started supporting consensus methods 15 and 16, but there's nothing in dir-spec.txt.

changed milestone to %Tor: 0.2.4.x-final

added component::core tor/tor milestone::Tor: 0.2.4.x-final owner::nickm priority::medium resolution::implemented status::closed tor-auth tor-spec type::defect labels

Here's what (I think) methods 15 and 16 do:

/** Lowest consensus method where microdescs may include a "p6" line. */
#define MIN_METHOD_FOR_P6_LINES 15

/** Lowest consensus method where microdescs may include an onion-key-ntor
 * line */
#define MIN_METHOD_FOR_NTOR_KEY 16

Looks like dir auths recently started supporting consensus methods 15 and 16, but there's nothing in dir-spec.txt.

Remember the workflow for proposals becoming implemented: First the proposal is Accepted, then we implement it and it becomes Finished, and then we integrate it into the specification and the proposal becomes Closed. It is a consequence of this process that the specifications are only a complete description of the latest Tor when amended with all proposals currently in state Finished.

That said, I'm leaving this open as a reminder to integrate the above-mentioned proposals into the specification.

Trac:
Milestone: N/A to Tor: 0.2.4.x-final
Keywords: tor-auth deleted, tor-auth spec added

Bulk-replacing "spec" and "torspec" keywords with "tor-spec".

Trac:
Keywords: tor-auth spec deleted, tor-auth tor-spec added

16 is documented in the in-review branch "document-ntor" (see #8122 (moved)). But 17 came into being. So, we should do that too.

Trac:
Summary: Consensus methods 15 and 16 are undocumented to Consensus methods 15 through 17 are undocumented
Owner: N/A to nickm
Status: new to accepted

15 is part of ef5513b1ad3671153f20b3c3929e1acba1b873bc in branch "more-specs" in my public repository; see #7826 (moved).

And method 17 is documented in 1c24c8fbdaa3fdb880d2d1ebb625e8569d89cca3 on branch "more-specs."

Trac:
Status: accepted to needs_review

+   The FLAGS value has one or more of the following bits set, where
+   "bit 1" is the LSB of the 32-bit value, and "bit 32" is the MSB.

Is FLAGS little-endian, big-endian, or middle-endian?

Trac:
Status: needs_review to needs_revision

It looks like the statement "All numeric values are encoded in network (big-endian) order" in section 0.1 wasn't explicit enough in what it covered. I've tried to make it more clear in b0cf07d3d81, and to clarify this explicit case.

Trac:
Status: needs_revision to needs_review

*this particular case

Merged it; thanks for the review!

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

closed

moved to tpo/core/tor#8094 (closed)