Re: [Netconf] Â Re:Â WGLCÂ forÂ draft-ietf-netcon f-tls-04.txt

----- Original Message -----
From: <badra@isima.fr>
To: "fanhuaxiangÂ 90002624Â" <washam.fan@huawei.com>
Cc: "Â" <netconf@ietf.org>
Sent: Sunday, September 28, 2008 12:22 PM
Subject: [Netconf] Re:Â Re:Â WGLCÂ forÂ draft-ietf-netcon f-tls-04.txt

> Dear Washam,
>
> Thank you for your reply.
> Here is the last text we agree on.
> Dear Juergen, based on Washam's comments, I think we need to keep such a
> text even if TLS describes this alert.
>
> 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). In
>    the case the receiver still has pending data to send, it SHOULD send
>    the pending data before sending the close_notify alert.
>

To quote TLS,
"The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes. "
so this proposed text would appear to contradict a TLS MUST.  TLS also takes
great care not to bind itself to TCP and not to prescribe the behaviour of the
underlying transport protocol.

And I imagine that this is what Juergen had in mind.  When we start to reproduce
TLS in our own words, we are likely to make things worse (perhaps also known as
the distributed database problem).  And for those with a sense of history, be
aware that the last call on syslog-tls completed precisely two years ago - and
the I-D is still  being revised:-(

Tom Petch

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf