Re: [Netconf] ��WGLC�for�draft-ietf-netcon f-t ls-04.txt

Hi David,

> FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review)
> has updated that section to make a clearer distinction between the TLS
> actions and the application actions. Transport sender and transport
> receiver refer to syslog application fuctionality, and they coordinate
> the closure actions.
>
>    A transport sender MUST close the associated TLS connection if the
>    connection is not expected to deliver any syslog messages later.
> It
>    MUST send a TLS close_notify alert before closing the connection.
> A
>    transport sender (TLS client) MAY choose to not wait for the
>    transport receiver's close_notify alert and simply close the
>    connection, thus generating an incomplete close on the transport
>    receiver (TLS server) side.  Once the transport receiver gets a
>    close_notify from the transport sender, it MUST reply with a
>    close_notify unless it becomes aware that the connection has
> already
>    been closed by the transport sender (e.g., the closure was
> indicated
>    by TCP).
>
>    When no data is received from a connection for a long time (where
> the
>    application decides what "long" means), a transport receiver MAY
>    close the connection.  The transport receiver (TLS server) MUST
>    attempt to initiate an exchange of close_notify alerts with the
>    transport sender before closing the connection.  Transport
> receivers
>    that are unprepared to receive any more data MAY close the
> connection
>    after sending the close_notify alert, thus generating an incomplete
>    close on the transport sender side.  When the transport sender (TLS
>    client) has received the close_notify alert from the transport
>    receiver and still has pending data to send, it SHOULD send the
>    pending data before sending the close_notify alert.
>

The same text is being used for NETCONF over TLS, with one exception, we
need to describe when to close connection for both sides (when client
doesn't want to initial any rpc operation or when the server found there
is no data on the wire for a long time).

(I sent the text to the mailing list this morning:
http://www.ietf.org/mail-archive/web/netconf/current/msg03838.html)

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