[Netconf] Re: Re: ?? WGLC for draft-ietf-net conf-t??ls-04.txt

[fanhuaxiang 90002624 <[e-mail]>]

Hi,
comments inline.
> > This does not really answer my question. Why is the text in the TLS
> > specs not sufficient? We should IMHO not include text is the TLS
> > specifications already cover things.
> 
> Dear Juergen,
> 
> What about modify the actual text as follows:
> 
> OLD:
> 
> 2.2. Connection Closure
> 
>   Either NETCONF peer MAY stop the NETCONF connection at any time and
>   therefore notify the other NETCONF peer that no more data on this
>   channel will be sent and that any data received after a closure
>   request will be ignored.  This MAY happen when no data is received
>   from a connection for a long time, where the application 
> decides what
>   "long" means.
> 
>   TLS has the ability From [e-mail]  Sat Sep 27 18:09:41 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 14FC03A6873;
	Sat, 27 Sep 2008 18:09:41 -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 3B6243A68B6
	for <[e-mail]>; Sat, 27 Sep 2008 18:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level: 
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5
	tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 KdLN7Ajd9-+N for <[e-mail]>;
	Sat, 27 Sep 2008 18:09:38 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211])
	by core3.amsl.com (Postfix) with ESMTP id 72FCB3A6842
	for <[e-mail]>; Sat, 27 Sep 2008 18:09:38 -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 18:09:18 -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 18:09:18 -0700 (PDT)
Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6])
	by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 09:09:01 +0800
Date: Sun, 28 Sep 2008 09:09:01 +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]>
Cc: =?iso-8859-7?Q?=C2?= <[e-mail]>
Subject: [Netconf] =?iso-8859-7?b?IFJlOiBSZTqgPz+gV0dMQ6Bmb3KgZHJhZnQtaWV0?=
 =?iso-8859-7?q?f-net_conf-t=3F=3Fls-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]

Hi,
comments inline.
> > This does not really answer my question. Why is the text in the TLS
> > specs not sufficient? We should IMHO not include text is the TLS
> > specifications already cover things.
> 
> Dear Juergen,
> 
> What about modify the actual text as follows:
> 
> OLD:
> 
> 2.2. Connection Closure
> 
>   Either NETCONF peer MAY stop the NETCONF connection at any time and
>   therefore notify the other NETCONF peer that no more data on this
>   channel will be sent and that any data received after a closure
>   request will be ignored.  This MAY happen when no data is received
>   from a connection for a long time, where the application 
> decides what
>   "long" means.
> 
>   TLS has the abfor secure connection closure using the Alert
>   protocol.  When the NETCONF peer closes the NETCONF connection, it
>   MUST send a TLS close_notify alert before closing the TCP 
> connection.   Any data received after a closure alert is ignored.
> 
>   Unless a fatal error has occurred, each party is required to 
> send a
>   close_notify alert before closing the write side of the connection
>   [RFC5246].  The other party MUST respond with a close_notify 
> alert of
>   its own and close down the connection immediately, discarding any
>   pending writes.  It is not required for the initiator of the 
> close to
>   wait for the responding close_notify alert before closing the read
>   side of the connection.
> 
> 
> NEW:
> 
> 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.  This notifies the
>   recipient that the sender will not send any more messages on this
>   connection.  Any data received after a closure alert is ignored.
>
IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time.
And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server.

washam
> 
> Like that, if people need more information on this alert 
> behaviour, they
> can refer to TLS document.
> 
> Best regards,
> Badra
> 
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


ility for secure connection closure using the Alert
>   protocol.  When the NETCONF peer closes the NETCONF connection, it
>   MUST send a TLS close_notify alert before closing the TCP 
> connection.   Any data received after a closure alert is ignored.
> 
>   Unless a fatal error has occurred, each party is required to 
> send a
>   close_notify alert before closing the write side of the connection
>   [RFC5246].  The other party MUST respond with a close_notify 
> alert of
>   its own and close down the connection immediately, discarding any
>   pending writes.  It is not required for the initiator of the 
> close to
>   wait for the responding close_notify alert before closing the read
>   side of the connection.
> 
> 
> NEW:
> 
> 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.  This notifies the
>   recipient that the sender will not send any more messages on this
>   connection.  Any data received after a closure alert is ignored.
>
IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time.
And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server.

washam
> 
> Like that, if people need more information on this alert 
> behaviour, they
> can refer to TLS document.
> 
> Best regards,
> Badra
> 
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf