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

[fanhuaxiang 90002624 <[e-mail]>]

Hi,
> Let's agree on a common text, please don't hesitate to propose 
> your text
> if the following isn't sufficient for you or if more correction is 
> needed.
> 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_noFrom [e-mail]  Sat Sep 27 22:27:33 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 B32EF3A696C;
	Sat, 27 Sep 2008 22:27:33 -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 5E1393A68AA
	for <[e-mail]>; Sat, 27 Sep 2008 22:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 
	BAYES_00=-2.599]
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 29ufJlepmHcw for <[e-mail]>;
	Sat, 27 Sep 2008 22:27:31 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211])
	by core3.amsl.com (Postfix) with ESMTP id 9FFCD3A681A
	for <[e-mail]>; Sat, 27 Sep 2008 22:27:31 -0700 (PDT)
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Sat, 27 Sep 2008 22:27:46 -0700 (PDT)
Received: from huawei.com ([172.17.1.36])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <[e-mail]> for
	[e-mail]; Sat, 27 Sep 2008 22:27:46 -0700 (PDT)
Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6])
	by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 13:27:29 +0800
Date: Sun, 28 Sep 2008 13:27:29 +0800
From: fanhuaxiang 90002624 <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug  8 2006)
Content-language: el
Content-disposition: inline
X-Accept-Language: el
Priority: normal
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Cc: =?iso-8859-7?Q?=C2?= <[e-mail]>
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Hi,
> Let's agree on a common text, please don't hesitate to propose 
> your text
> if the following isn't sufficient for you or if more correction is 
> needed.
> 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 atify 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).
I'd like add below sentence to the end of the paragraph.
"in the case 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


lert 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).
I'd like add below sentence to the end of the paragraph.
"in the case 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