The Secure Shell (SSH) Session Channel Break Extension
draft-ietf-secsh-break-04

[Ballot comment]
From review by Elwyn Davies:

s1: para 1: Add a reference to the SSH Connection protocol [5] after 'session channel'.
s3: Choose between 'break-length' (as in message format) and 'BREAK-length' (as in para 4).
s3: next to last para: (2 places) s/preformed/performed/

[Ballot discuss]
This is a very minor point but it needs clearing up.

From review by Elwyn Davies:

Possible issue:
[I say 'possible' because I am not an ssh expert but there is an apparent inconsistency with other ssh documents which makes me wonder].
s2: para 4: The text says 'If the BREAK-length parameter is 0 *or not present*, the BREAK SHOULD be interpreted...'. As far as I can see no other ssh message has optional parameters in this way. Although it would obviously be possible to cope with both cases, it seems to be unusual and makes parsing the message more complex than it needs to be, given that this message is going to be a relative rarity. Was this intended? If so I think it would be desirable to add an explicit note closer to the message definition to point out that the parameter is optional. Otherwise just delete 'or not present'.

BC: As I read the spec, the channel request always includes
  uint32    break-length in milliseconds
so the case where the break-length parameter is absent simply doesn't
exist. If that's correct, indeed just delete 'or not present'.

[Ballot comment]
A normative reference to SSH should really be included with this sentence fragment noted in Section 1:

"The Secure Shell (SSH) session channel"

maybe this?:

"The Secure Shell (SSH) [5] session channel"

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes. 

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Adequate review has occurred from WG members, and it has been reviewed
by people with subject-matter expertise in terminal/console servers and
similar devices.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus to publish this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

Yes.

  1.ijk) Write-up section:

        *    Technical Summary
        *    Technical Summary
The Session Channel Break Extension provides a means to send a BREAK
signal over a Secure Shell (SSH) terminal session. 

        *    Working Group Summary

The consensus of the working group was to publish this as a
standards-track document.

        *    Protocol Qualityn

This extension is a replacement for vendor-specific hacks which
provide the same functionality.  There are known to be multiple
interoperable implementations of this extension and substantial vendor
interest.