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

[Mohamad Badra <[e-mail]>]

tom.petch wrote:
 >>Juergen Schoenwaelder wrote:
 >>>fanhuaxiang 90002624 wrote:
> 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.

 >> maybe what said in counterpart section in syslog-tls  contradict a 
 >>TLS MUST, too.

>>> I think the value of section "connection closure" is to describe
>>> when and how to end up a connection. so I think maybe we need to
>>> elaborate what "TLS connection is not used anymore" means in netconf
>>> context.
>>> 
>>> It is the application's decision and hence any discussion is either
>>> pointless or likely getting it wrong.

To quote IESG Evaluation on syslog-tls,

   "Section 4.4:
    OLD:
       A TLS client 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 client MAY choose to not wait for the server's
       close_noFrom [e-mail]  Mon Sep 29 04:45:50 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 31AC23A6832;
	Mon, 29 Sep 2008 04:45:50 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E1CAB3A6832
	for <[e-mail]>; Mon, 29 Sep 2008 04:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.544
X-Spam-Level: 
X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.705, 
	BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0e+Y+--PXv2a for <[e-mail]>;
	Mon, 29 Sep 2008 04:45:47 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id F05F43A6784
	for <[e-mail]>; Mon, 29 Sep 2008 04:45:46 -0700 (PDT)
Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158])
	by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m8TCjKc21085592;
	Mon, 29 Sep 2008 13:45:21 +0100
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2008 13:44:20 +0200
From: Mohamad Badra <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: fanhuaxiang 90002624 <[e-mail]>,
	Juergen Schoenwaelder <[e-mail]>, [e-mail]
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
	(sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 13:45:21 +0100 (WEST)
Cc: [e-mail]
Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: [e-mail]
Errors-To: [e-mail]

tom.petch wrote:
 >>Juergen Schoenwaelder wrote:
 >>>fanhuaxiang 90002624 wrote:
> 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.

 >> maybe what said in counterpart section in syslog-tls  contradict a 
 >>TLS MUST, too.

>>> I think the value of section "connection closure" is to describe
>>> when and how to end up a connection. so I think maybe we need to
>>> elaborate what "TLS connection is not used anymore" means in netconf
>>> context.
>>> 
>>> It is the application's decision and hence any discussion is either
>>> pointless or likely getting it wrong.

To quote IESG Evaluation on syslog-tls,

   "Section 4.4:
    OLD:
       A TLS client 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 client MAY choose to not wait for the server's
       close_notify atify alert and simply close the connection, thus
       generating an incomplete close on the server side.  Once the
       server gets a close_notify from the client, it MUST reply with a
       close_notify unless it becomes aware that the connection has
       already been closed by the client (e.g., the closure was
       indicated by TCP).
    NEW:
       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).

    Section 4.4:
    OLD:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a server MAY
       close the connection.  The server MUST attempt to initiate an
       exchange of close_notify alerts with the client before closing
       the connection.  Servers 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 client side.
       When the client has received the close_notify alert from the
       server and still has pending data to send, it SHOULD send the
       pending data before sending the close_notify alert.
    NEW:
       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."


I think the above text would appear to contradict a TLS MUST.  Wouldn't?

I also think the above text describes when to close connection for both 
sides. e.g, when the client doesn't want to initial any syslog message 
or when the server found there is no data on the wire for a long time.

With respect to that, I think we should propose a simalar text, a 
modified text is below:

       "A TLS client (NETCONF manager) MUST close the associated TLS
       connection if the connection is not expected to deliver any rpc
       operation later.  It MUST send a TLS close_notify alert before
       closing the connection.  The client MAY choose to not wait for the
       TLS server (NETCONF agent) close_notify alert and simply close the
       connection, thus generating an incomplete close on the server
       side.  Once the server gets a close_notify from the client, 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 TLS server MAY close
       the connection.  The TLS server MUST attempt to initiate an
       exchange of close_notify alerts with the transport sender before
       closing the connection. The server that is unprepared to receive
       any more data MAY close the connection after slert and simply close the connection, thus
       generating an incomplete close on the server side.  Once the
       server gets a close_notify from the client, it MUST reply with a
       close_notify unless it becomes aware that the connection has
       already been closed by the client (e.g., the closure was
       indicated by TCP).
    NEW:
       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).

    Section 4.4:
    OLD:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a server MAY
       close the connection.  The server MUST attempt to initiate an
       exchange of close_notify alerts with the client before closing
       the connection.  Servers 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 client side.
       When the client has received the close_notify alert from the
       server and still has pending data to send, it SHOULD send the
       pending data before sending the close_notify alert.
    NEW:
       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."


I think the above text would appear to contradict a TLS MUST.  Wouldn't?

I also think the above text describes when to close connection for both 
sides. e.g, when the client doesn't want to initial any syslog message 
or when the server found there is no data on the wire for a long time.

With respect to that, I think we should propose a simalar text, a 
modified text is below:

       "A TLS client (NETCONF manager) MUST close the associated TLS
       connection if the connection is not expected to deliver any rpc
       operation later.  It MUST send a TLS close_notify alert before
       closing the connection.  The client MAY choose to not wait for the
       TLS server (NETCONF agent) close_notify alert and simply close the
       connection, thus generating an incomplete close on the server
       side.  Once the server gets a close_notify from the client, 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 TLS server MAY close
       the connection.  The TLS server MUST attempt to initiate an
       exchange of close_notify alerts with the transport sender before
       closing the connection. The server that is unprepared to receive
       any more data MAY close the connection after sendingending the
       close_notify alert, thus generating an incomplete close on the
       client side.  When the client has received the close_notify alert
       from the server and still has pending data to send, it SHOULD send
       the pending data before sending the close_notify alert."


Comments?
Best regards,
Mohamad Badra
CNRS - LIMOS Laboratory

_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


 the
       close_notify alert, thus generating an incomplete close on the
       client side.  When the client has received the close_notify alert
       from the server and still has pending data to send, it SHOULD send
       the pending data before sending the close_notify alert."


Comments?
Best regards,
Mohamad Badra
CNRS - LIMOS Laboratory

_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf