core draft nits

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

A few nits we may want/need to fix, as long as we're going to have to do
another rev of the core drafts.

* architecture, section 3.1 (Host Keys)
  > Each server host SHOULD have a host key.
  > [...}
  > If a host has keys at all, it MUST have at least one key using each
  > REQUIRED public key algorithm (currently DSS [FIPS-186])

  How did these statements make it through?  "MUST is for implementors";
  we can't tell a server operator he must have a particular type of host
  key.  We should instead be saying that implementations MUST support the
  required algorithm

* transport, section 4.2 (Compression)
  Fails to specify that the initial compression algorithm MUST be "none".
  While this should be obvious, implementors need to know it in order to
  get the initial algorithm negotiation right, so IMNSHO it should be
  spelled out.

* transport, section 4.3 (Encryption)
  Fails to specify that the initial encryption algorithm MUST be "none".
  Again, this should be obvious, but implementors need to know, so we
  should spell it out.


The remaining issues all have to do with IANA considerations, and I feel
that they must be addressed before the documents can be resubmitted to the
IESG, if we want to avoid yet another round of editing and/or mass
confusion on the part of the IANA.


* transport, section 9.1 (Disconnection Message)
  Fails to specify the mechanism for assigning new disconnect reason codes.

* connect, section 4.10 (Returning Exit Status)
  Defines a different extension mechanism for signal names than that used
  by every other name type used in the ssh protocol.  It should use the
  same mechanism, with names containing an '@' to be delegated to the
  owner of the specified domain, and names not containing an '@' assigned
  by IETF concensus (possibly we can delegate some or all of that space
  to POSIX).  IMHO we should resolve at least the first part of this issue
  now; the discussion of whether and how to delegate part or all of the
  IETF namespace can be deferred for the next round.

* connect, section 6 (Encoding of Terminal Modes)
  Fails to specify the mechanism for assigning new terminal mode opcodes.

* architecture, section 7 (IANA considerations)
  This section is good as far as it goes, but it fails to provide an
  exhaustive list of the registries which the IANA is expected to
  maintain.  In addition, for each registry we need to provide a pointer
  to a complete list of the values to be registered initially.


The following is what I believe to be a complete list of registries to be
created.  For those registries for which there is not already a complete
list of values in one of the core drafts, I have included one here.

  - message numbers (architecture, section 6; listed there)

  - compression methods (transport, section 4.2; listed there)

  - encryption algorithms (transport, section 4.3; listed there)

  - MAC algorithms (transport, section 4.4; listed there)

  - key exchange methods (transport, section 4.5; listed there)

  - public key algorithms (transport, section 4.6; listed there)

  - service names (transport, section 8; listed there)

  - disconnect reason codes (transport, section 9.1; listed there)

  - user authentication methods (userauth, section 2):
    + "none" (2.3)
    + "publickey" (4)
    + "password" (5)
    + "hostbased" (6)

  - global requests (connect, section 2):
    + "tcpip-forward" (5.1)
    + "cancel-tcpip-forward" (5.1)

  - channel types (connect, section 3.1)
    + "session" (4)
    + "x11" (4.3.2)
    + "forwarded-tcpip" (5.2)
    + "direct-tcpip" (5.2)

  - channel requests for the "session" channel (connect, section 4):
    + "pty-req" (4.2)
    + "x11-req" (4.3.1)
    + "env" (4.4)
    + "shell" (4.5)
    + "exec" (4.5)
    + "subsystem" (4.5)
    + "window-change" (4.7)
    + "xon-xoff" (4.8)
    + "signal" (4.9)
    + "exit-status" (4.10)
    + "exit-signal" (4.10)

  - subsystem names (connect, section 4.5; none currently defined)

  - terminal mode opcodes (connect, section 6; listed there)

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA