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

[Mohamad Badra <[e-mail]>]

My apologies, I forgot to include Washam comments "in netconf case, both 
sides are expected to send data"

So please forget my last text, below is the correct one:


       "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 NETCONF peer MAY
       close the connection.  The peer MUST attempt to initiate an
       exchange of close_notify alerts with the other NETCONF peer before
       closing the connection. The close_notify's sender that is
       unpreFrom [e-mail]  Mon Sep 29 05:14:20 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 AEA1A3A69A1;
	Mon, 29 Sep 2008 05:14:20 -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 7A85C3A68CE
	for <[e-mail]>; Mon, 29 Sep 2008 05:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.294
X-Spam-Level: 
X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.355, 
	BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6]
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 Txwu5PjQPwbC for <[e-mail]>;
	Mon, 29 Sep 2008 05:14:18 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 03D4B3A68F5
	for <[e-mail]>; Mon, 29 Sep 2008 05:14:17 -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 m8TDEXrd634974;
	Mon, 29 Sep 2008 14:14:35 +0100
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2008 14:13:33 +0200
From: Mohamad Badra <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: fanhuaxiang 90002624 <[e-mail]>
References: <[e-mail]>
	<[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 14:14:35 +0100 (WEST)
Cc: Juergen Schoenwaelder <[e-mail]>, [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: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: [e-mail]
Errors-To: [e-mail]

My apologies, I forgot to include Washam comments "in netconf case, both 
sides are expected to send data"

So please forget my last text, below is the correct one:


       "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 NETCONF peer MAY
       close the connection.  The peer MUST attempt to initiate an
       exchange of close_notify alerts with the other NETCONF peer before
       closing the connection. The close_notify's sender that is
      pared to receive any more data MAY close the connection after
       sending the close_notify alert, thus generating an incomplete
       close on the close_notify's receiver side.  When the receiver
       has received the close_notify alert from the sender and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."


Best regards
Mohamad Badra
CNRS - LIMOS Laboratory

Mohamad Badra a écrit :
> 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 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  unprepared to receive any more data MAY close the connection after
       sending the close_notify alert, thus generating an incomplete
       close on the close_notify's receiver side.  When the receiver
       has received the close_notify alert from the sender and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."


Best regards
Mohamad Badra
CNRS - LIMOS Laboratory

Mohamad Badra a écrit :
> 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 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 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."
> 
> 
> Comments?
> Best regards,
> Mohamad Badra
> CNRS - LIMOS Laboratory
> 

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


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 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."
> 
> 
> Comments?
> Best regards,
> Mohamad Badra
> CNRS - LIMOS Laboratory
> 

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