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

[[e-mail]]

Dear all,

Below is a new tentative to agree on the text related to the Section
'Connection Closure'.  The text is much closed to Section 4.4 of
draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both
the agent and the manager may send data.

   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 TLS 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 TLS server side.  Once the
   TLS server gets a close_notify from the TLS client, it MUST reply with
   a close_notify unless it becomes aware that the connection has already
   been closed by the TLS client (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 NETCONF 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 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.

Comments?
Best regards,
Badra
_______From [e-mail]  Mon Oct  6 11:20:02 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 2EC7C28C1D9;
	Mon,  6 Oct 2008 11:20:02 -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 BCAA328C14D
	for <[e-mail]>; Mon,  6 Oct 2008 11:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.77
X-Spam-Level: 
X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.380, 
	BAYES_20=-0.74, 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 9dJv6QNtwFbw for <[e-mail]>;
	Mon,  6 Oct 2008 11:19:55 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 1DC4328C1A8
	for <[e-mail]>; Mon,  6 Oct 2008 11:19:54 -0700 (PDT)
Received: from www.isima.fr ([e-mail] [193.55.95.79])
	by sp.isima.fr (8.13.8/8.13.8) with SMTP id m96JJvdd966810
	for <[e-mail]>; Mon, 6 Oct 2008 20:19:57 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Mon, 6 Oct 2008 20:18:28 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 6 Oct 2008 20:18:28 +0200 (CEST)
From: [e-mail]
To: [e-mail]
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
	(sp.isima.fr [193.55.95.1]); Mon, 06 Oct 2008 20:19:57 +0100 (WEST)
Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Dear all,

Below is a new tentative to agree on the text related to the Section
'Connection Closure'.  The text is much closed to Section 4.4 of
draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both
the agent and the manager may send data.

   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 TLS 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 TLS server side.  Once the
   TLS server gets a close_notify from the TLS client, it MUST reply with
   a close_notify unless it becomes aware that the connection has already
   been closed by the TLS client (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 NETCONF 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 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.

Comments?
Best regards,
Badra
_____________________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


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