Re: additional core draft nits in need of WG attention.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

> >If we really want to get rid of this possibility, the cleanest and least
> >confusing way of doing it would be to define protocol version 2.1 with a
> >changed KEXINIT format,
> 
> I don't really know if such a big change is necessary, just
> discouraging the use of asymmetric choices (which shouldn't be hard
> given that nothing (?) does it at the moment, so any attempt to
> implement it will fail to interop) should be enough.  No need to
> break things.

The proposal during the WG session was that we should add text so that
for both algorithms and language tags, the negotiated value SHOULD be
the same in both directions.  I'll send a more precise recommended
edit in the next day or two..

Note the RFC2119 definition of SHOULD:
   
   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
   there may exist valid reasons in particular circumstances to ignore
   a particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Note that this is somewhat stronger than the plain-english meaning of
SHOULD.

Given the current state of the documents (near approval by the IESG),
I'm extremely reluctant to make a larger change at this point.

We can revisit this issue when we move beyond Proposed Standard.

(The process for advancement to Draft Standard requires that we
document that all of the protocol features interoperate.  if nobody
has actually implemented asymmetric algorithms, we can strike it at
that point).

					- Bill

P.S., There are certainly a few obscure applications where it makes
sense to use different algorithms in each direction.  One which comes
to mind is the case of a remote sensor/space probe/etc., where the
"uplink" is low data-rate management/control traffic, where strong
integrity protection is required to prevent the probe from being
hijacked, and the "downlink" is a higher-volume, lower-value data
stream, where weak integrity protection may be sufficient.