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

[[e-mail]]

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 conneFrom [e-mail]  Sun Sep 28 03:24:08 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 848123A68A0;
	Sun, 28 Sep 2008 03:24:08 -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 2CA9C3A68A0
	for <[e-mail]>; Sun, 28 Sep 2008 03:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.587, 
	BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3,
	SARE_SUB_ENC_UTF8=0.152]
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 QLfVeKHiA6pT for <[e-mail]>;
	Sun, 28 Sep 2008 03:24:06 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 7FA5B3A67F4
	for <[e-mail]>; Sun, 28 Sep 2008 03:24:04 -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 m8SBNpdF782532;
	Sun, 28 Sep 2008 12:23:51 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Sun, 28 Sep 2008 12:22:51 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]>
	<[e-mail]>
Date: Sun, 28 Sep 2008 12:22:51 +0200 (CEST)
From: [e-mail]
To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= <[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]); Sun, 28 Sep 2008 12:23:52 +0100 (WEST)
Cc: =?utf-8?Q?=C2?= <[e-mail]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgUmU6wqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYt?=
 =?utf-8?q?netcon__f-tls-04=2Etxt?=
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 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.

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


ction, 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.

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