IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WG Chair Copyediting for draft-ietf-secsh-break-02
Ugh. How embarassing. I apologize for failing to do enough grammar
checking. I promise that -03 will be better. And spell checked, too.
> Alternatively, support for the BREAK facility MAY be imlemented
> 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.
> 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.
Yes, that is exactly what I meant.
> 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/
I agree with that change.
> 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.
"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?
> 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.
Great.
> Implementations MAY allow an administrator to adjust the default,
minimum,
> 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.
Home |
Main Index |
Thread Index |
Old Index