On 14 Dec 2017, at 12:46, isis agora lovecruft <isis@torproject.org> wrote:

6.1. New Subprotocols and Subprotocol Versions

  This proposal introduces, following prop#264, the following new
  subprotocol numbers and their uses.

6.1.1. Relay Subprotocol

    "Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V
      and CREATED2V cells and their above specification for link-layer
      authentication specifiers.

We usually specify that the numbers will be allocated when the proposal

is merged. That avoids gaps in the numbering, and weird semantics like

"4 doesn't support 3".

In particular, an upcoming IPv6 proposal will need a new Relay protover,

and it might get merged in 0.3.3.

6.1.2. Link Subprotocol

    "Link 5": The OP supports all of "Link 1-4", plus support for the new
      EXTEND2 semantics. Namely, it understands that an EXTEND2 cell whose
      "hlen" field is greater than 505 will be followed by further "hdata"
      in fragmented EXTEND2 cells which MUST follow. It also understands
      that the following combination of EXTEND2 payload specifiers
      indicates that the cell is a continuation of the earlier payload
      portions:

          nspec = 0;
          htype = 0xffff;
          hlen = 0;

Link version 5 is link padding, which was merged in 0.3.2:

6.1.3. Handshake Subprotocol

  Additionally, we introduce a new subprotocol, "Handshake" and the
  following number assignments for previously occuring instances:

    "Handshake 1" -- The OP supports the TAP handshake.

    "Handshake 2" -- The OP supports the ntor handshake.

  We also reserve the following assignments for future use:

    "Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake
      from prop#269.

    "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum
      secure hybrid handshake, that is, the "hybrid+null" handshake from
      "Handshake 3", except with "null" part replaced with another (as yet
      unspecified) protocol to be composed with the ntor-like ECDH-based
      handshake.

  Further handshakes MUST be specified with "Handshake" subprotocol
  numbers, and MUST NOT be specified with "Relay" subprotocol numbers. The
  "Relay" subprotocol SHALL be used in the future to denote changes to
  handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE,
  CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V,
  CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2.

  Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and
  likewise "Handshake 2" is with "Relay 2".

Since this is a new protover field, it's ok to reserve numbers :-)

6.2. Subprotocol Recommendations

  After the subprotocol additions above, we change to recommending the
  following in the consensus:

     recommended-client-protocols […] Link=5 Relay=3 Handshake=2
     recommended-relay-protocols […] Link=5 Relay=3 Handshake=2

I don't think we will want to jump straight to recommending the highest

Is there a reason for this?

Does it lead to warnings on clients or relays?

required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2
required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2