Subject: WG Chair Copyediting for draft-ietf-secsh-break-02

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 21 Apr 2004 16:09:34 -0400

I found a few nits:

1) I Garbled sentence in the
security considerations section:

   Alternatively, support for the BREAK facility MAY be imlemented
   configurable or a per port or per server basis.

The meaning is clear but could definitely use some sanding and
polishing.

2) misplaced comma and missing article:

change:

   If  BREAK duration request of less than 500ms, is
   requested a BREAK of 500ms SHOULD be sent since most devices will
   recognize a BREAK of that length.

to:

   If a BREAK duration request of less than 500ms is requested, a BREAK
   of 500ms SHOULD be sent since most devices will recognize a BREAK
   of that length.

3) spelling error, ambiguity:

   If
   a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be
   sent.  If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be

s/preformed/performed or passed on/

(fix typo; clarify that the server doing break-passthrough NEED NOT
wait for the break to be ack'ed, as this may not be possible to do
reliably in some cases).

---

And, I couldn't help myself:

Break-length section rewording:

   A BREAK-length parameter of 0 is a request for a default-length break;
   by default, this SHOULD be a 500ms break.

   Some implementations will not be in a position to control the
   length of a BREAK; such implementations SHOULD instead generate an
   fixed-length break of an implementation-defined length in response
   to this request.

   Others SHOULD limit the minimum and maximum length of BREAK
   durations.  The encoding specified above allows a sender to request
   a maximum BREAK duration of approximately 49.7 days.  

   By default, durations less than 500ms SHOULD be silently extended
   to 500ms (as some devices may not recognize BREAKS much shorter
   than this); durations longer than 3000ms SHOULD be silently truncated to
   3000ms.

   Implementations MAY allow an administrator to adjust the default, minimum,
   and maximum break lengths.

---

Let's have a quick 1-week WG review on this followed by a respin.

WG members: please review this document and send comments on or before
4/28/2004

						- Bill

---

From: "Phillip Remaker" <[email-masked]>
Date: Wed, 21 Apr 2004 13:22:05 -0700

Ugh.  How embarassing.  I apologize for failing to do enough grammar
checking.  I promise that -03 will be better.  And spell checked, too.

>    configurable or a per port or per server basis.

How about

The support for BREAK over SSH MAY be implemented such that the recognition
of BREAK over SSH may be activated or deactivated a per port or per server
basis.

>    of 500ms SHOULD be sent since most devices will recognize a BREAK

Yes, that is exactly what I meant.

> s/preformed/performed or passed on/

I agree with that change.

>    fixed-length break of an implementation-defined length in response

"implementation-defined."  Hmmm.  What I am really trying to say here is
that if the coder has no control over the break length, a break of any
available length should be sent.  That is, if you only available command is
to tell a chipset to "send a break," that is what you should do.  How best
to word that?

>    than this); durations longer than 3000ms SHOULD be silently truncated
to

Great.

>    and maximum break lengths.

..up to and including the bizzare and ridculous lengths, of course 8-)

Thanks for the quick review.  I will happily spin up -03 next week with the
comments incorporated.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 21 Apr 2004 16:40:51 -0400

> to tell a chipset to "send a break," that is what you should do.  How best

I was thinking about it from an outside-the-system-box perspective.

The ssh(d) module may can't control it, but some other piece of the
system (serial chipset, device driver, serial i/o subsystem, etc.)
may be the entity which controls it in an
implementation-of-that-piece-of-the-system-defined manner.

That then becomes an implementation-defined property of the system as
a whole.

Anyone else got a wording suggestion?

						- Bill

---

From: "Phillip Remaker" <[email-masked]>
Date: Wed, 21 Apr 2004 16:39:09 -0700

> implementation-of-that-piece-of-the-system-defined manner.

Exactly.  I knew what you meant.  But since there is "the implementation of
sshd" and the "implementation of the drivers" and the "implementation of the
UART/chipset," I want to be clear that implementation specific is not the
responsibility of the writer of the SSHD

"If the SSH server responsible for sending the break has no control over the
hardware that sends break length (as in an opaque UART driver), or has no
way to pass break length information (as in an SSH to telnet gateway), the
implementation MAY (MUST?) still send a BREAK signal, omitting the length
information.  Sending a break signal without the length information is still
considered a successful sending of a BREAK."

Bottom line:  Break length is a SUGGESTION, which may be used by the
receiver if it is so capable..