Section 2.1: "It MUST connect to the server that pa=
ssively listens for the incoming TLS connection on the TCP port 6513".=
=A0This language eliminates the possibility of implementing a "revers=
e-tls" mechanism like we have with "reverse-ssh". =A0Since o=
ne of the motivators for this work is to support low-end devices, I would t=
hink a need for a call-home mechanism would be desired. =A0That said, it mi=
ght be hard to implement since SSH uses a named subsystem ("netconf&qu=
ot;), maybe this is more reason to support bidirectional TLS connections? [=
Note: this language was also in RFC5539]

RFC5246 doesn't support=
reverse proxy as well, and all RFCs' Applications over TLS have the sa=
me above language.=A0

However, what about=A0rewrit=
ing=A0it as follow:

The peer actively =
opens the TLS connection, and the server passively

listens for the incoming TLS connection.

=A0

Section 2.2: wh=
at about <close-session>? =A0- why define another mechanism? =A0If im=
portant, then why doesn't RFC6242 require the client to send SSH_MSG_CH=
ANNEL_CLOSE and/or SSH_MSG_DISCONNECT. =A0 Regardless, I disagree with the =
intent of forcing graceful closures - in reality, devices MUST be coded to =
support ungraceful closures and, once the code is written, there isn't =
much value to a graceful close anymore. =A0Also the second paragraph seems =
out of place - shouldn't it be in the TLS RFC? [Note: this language was=
also in RFC5539]

Section 3.1 - RFC4642 places these recommendations into its "Security =
Considerations" section - should this draft do the same? =A0If this dr=
aft is going to specify this information, then should it first state that t=
he client SHOULD validate the server's certificate chain (i.e. a truste=
d CA, no expirations, no revocations, etc.)? =A0Note: this language was als=
o in RFC5539]

I would prefer not moving i=
t to the "Security Considerations" and I will replace the 1st par=
agraph with

If the server's presented cer=
tificate has passed

c=
ertification path validation [RFC5280] to a configured

trust anchor, the client MUST carefully examine the

certificate presented by the serv=
er to determine if it meets the

client's expectations. Particularly, the client MUST check =
its

understanding of the server hostn=
ame against the server's identity as

presented in the server Certificate message, in order t=
o prevent man-

in-the-middle attacks.

<=
/div>

Section 3.2.1 -
Section 3.2.1.1=A0
Section 3.2.1.3

Alan and Juergen will b=
e able to address your concerns much better than me.