Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

Dear Washam,

> IMHO, we may need to describe when to close connection for both sides.e.g,
> when client don't want to initial any rpc operation or server found there
> is no data on the wire for a long time.
> And, I wanna express there is a difference between syslog and netconf
> scenarios. in syslog case, only client is expected to send data, so
> syslog-tls says "client SHOULD send the pending data before sending the
> close_notify alert", whilst in netconf case, both sides are expected to
> send data, so the same words should be applied to client and server.

Let's agree on a common text, please don't hesitate to propose your text
if the following isn't sufficient for you or if more correction is needed.

2.2. Connection Closure

   TLS [RFC5246] has the ability for secure connection closure using the
   Alert protocol.  Either NETCONF peer MAY stop the NETCONF connection at
   any time by sending a TLS close_notify alert.

   A NETCONF peer MUST close the associated TLS connection if the
   connection is not expected to deliver any rpc operation or when no data
   is received from a connection for a long time, where the application
   decides what "long" means.  The NETCONF peer MUST send a TLS
   close_notify alert before closing the connection.  A sender's
   close_notify MAY choose to not wait for the receiver's close_notify
   alert and simply close the connection, thus generating an incomplete
   close on the receiver's close_notify side.  Once the receiver gets a
   close_notify from the sender's close_notify, it MUST reply with a
   close_notify unless it becomes aware that the connection has already
   been closed by the sender (e.g., the closure was indicated by TCP).

Best regards,
Badra
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf