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