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

[fanhuaxiang 90002624 <[e-mail]>]

Hi,
> On Sun, Sep 28, 2008 at 12:22:51PM +0200, [e-mail] wrote:
> 
> > 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.
> 
> I don't really see the value of this sentence. Essentially the text
> says "an application MUST close the TLS connection if the application
> believes the TLS connection is not used anymore" - somFrom [e-mail]  Mon Sep 29 03:35:23 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 89AF63A6981;
	Mon, 29 Sep 2008 03:35:23 -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 0F6043A6A5D
	for <[e-mail]>; Mon, 29 Sep 2008 03:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[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 LWzQgC8iilDY for <[e-mail]>;
	Mon, 29 Sep 2008 03:35:22 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211])
	by core3.amsl.com (Postfix) with ESMTP id 35D913A6979
	for <[e-mail]>; Mon, 29 Sep 2008 03:35:22 -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]; Mon, 29 Sep 2008 03:35:14 -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]; Mon, 29 Sep 2008 03:35:14 -0700 (PDT)
Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106])
	by szxmc04-in.huawei.com (mshttpd); Mon, 29 Sep 2008 18:34:57 +0800
Date: Mon, 29 Sep 2008 18:34:57 +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]>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Hi,
> On Sun, Sep 28, 2008 at 12:22:51PM +0200, [e-mail] wrote:
> 
> > 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.
> 
> I don't really see the value of this sentence. Essentially the text
> says "an application MUST close the TLS connection if the application
> believes the TLS connection is not used anymore"ething rather
> obvious and I am not sure an explicit MUST is needed.
> 
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.
> >    The NETCONF peer MUST send a TLS close_notify alert before
> >    closing the connection.
> 
> But I think you can't rely on being able to do this in all cases.
> Perhaps this should be a SHOULD instead of a MUST.
>
isn't it what TLS rfc specify how to close a 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). 
> 
> See above - I assume a SHOULD is more appropriate than a MUST.
> 
> >    In the case the receiver still has pending data to send, it
> >    SHOULD send the pending data before sending the close_notify
> >    alert.
> 
> Here I agree with the SHOULD. ;-)
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


 - something rather
> obvious and I am not sure an explicit MUST is needed.
> 
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.
> >    The NETCONF peer MUST send a TLS close_notify alert before
> >    closing the connection.
> 
> But I think you can't rely on being able to do this in all cases.
> Perhaps this should be a SHOULD instead of a MUST.
>
isn't it what TLS rfc specify how to close a 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). 
> 
> See above - I assume a SHOULD is more appropriate than a MUST.
> 
> >    In the case the receiver still has pending data to send, it
> >    SHOULD send the pending data before sending the close_notify
> >    alert.
> 
> Here I agree with the SHOULD. ;-)
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf