Open Issues from Recent Comments

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

We've received some coments recently.  I'll summarize them and note what I
intend to do with them in the core IDs.  I'd appreciate feedback.


1)  Double spaces after the period after an initial in a name.
Issue:  xml2rfc has started double spacing between the end of a sentence
and the start of the next.  I saw that problem with "etc." used at the end
of a sentence.
Proposed Resolution:  I'm not sure what I can do about this but I'll play
around and see.


2)  Use of commas in "..may, or may not be.."
Issue:  English grammar.
Proposed Resolution:  My Scribner Handbook of English (after cleaning off
all of the dust) says that it's OK to have "..may or may not.." without
commas.  I'll clean those up.


3)  Use of commas in "..display forwarding in SSH (or other, secure
protocols), combined with.."
Issue:  English grammar.
Proposed Resolution:  I'll make the change to "display forwarding in SSH
(or other secure protocols), combined with..".


4)  SSH_DISCONNECT_* descriptions
Issue:  (From the note by der Mouse)  In sections 4.2 and 4.2.2 of
[NUMBERS]-10, the table headings make it appear that the SSH_DISCONNECT_*
names *are* the "description" strings appearing in an SSH_MSG_DISCONNECT
packet, which I assume is false - if that were true, the "description"
would carry no information not already present in the "reason code".
Specifically, the (new) first two lines of text in 4.2.2 comes very close
to stating that the table shows the strings as they must appear in a
DISCONNECT packet.  The text around line 425 further implies that the
"description" strings are standardized, which I had thought was not the
case - and which makes no sense because they then carry no information and
might as well be skipped.
Proposed Resolution:  Can I get some feedback on this?  I was under the
assumption that the "descriptions" are the standardized text to send in
the "description" field.  I too felt that was a bit redundant but figured
that it was setting the precendence for the descriptions associated with
local namespaces.  What's the right thing to do here?


5)  Opcode Arguments in [NUMBERS]-10 and [CONNECT]-23
Issue:  TTY_OP_END is listed with the prefix of "TTY_OP_" but none of the
others include that prefix.
Proposed Resolution:  I need some feedback on this as well.  Do the opcode
arguments all get the prefix of "TTY_OP_"?


6)  PENDIN opcode
Issue:  Why does PENDIN have an assignment.  It is really a dynamic tty
driver internal state.  It may not be the sort of state bit that it makes
any sense at all to push across the network.
Proposed Resolution:  I need someone to verify that.


7)  SPKI
Issue:  (From note by Peter Gutmann) The incompletely-specified X.509
format has been removed but the totally unspecified SPKI format (RFC2693
specifies neither a cert nor signature format, that was in the
long-expired draft-ietf-spki-certstructure, so it's not possible to
provide either a cert or a "signature blob in format specific encoding")
and the incompletely-specified PGP format (RFC2440 specifies a large
number of options, signed attributes, packet types, etc etc for
signatures) are still present.  These should really be removed as well if
it's not possible for anyone to implement them.
Proposed Resolution:  I'll remove SPKI where appropriate unless anyone has
a better proposal.


8)  UTF8
Issue:  The Editor is not sure what to do with all of the emails flying
back and forth.
Proposed Resolution:  Unless we get some consensus on proposed text, I'm
not going to make any modifications to the IDs.


9)  KEX Message Numbers
Issue:  (From note by Ben Harris) Requests for assignments of new message
numbers in the range of 1 to 127 MUST be done through the STANDARDS ACTION
method as described in [RFC2434].
This seems slightly wrong to me, in that message numbers in the ranges
30-49 and 60-79 are effectively assigned by whoever owns the KEX or
USERAUTH method in use, not by IANA (thought of course some KEX and
USERAUTH names are assigned by IANA.
Proposed Resolution:  This sounds right to me.  Unless someone objects,
I'll integrate the wording proposed by Ben into [NUMBERS] and duplicate it
in [USERAUTH].


Thanks,
Chris