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

[[e-mail]]

> On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote:
>> Hi,
>> in section 2, it says,
>> "The other party MUST respond with a close_notify alert of
>> its own and close down the connection immediately, discarding any
>> pending writes"
>> I wanna ask why immediately instead of sending pening writes before
>> close down the connection.
>
> And I like to add whether it is normal practice that the TLS teardown
> procedure is application protocol specific. RFC 5246 section 7.2.1
> discusses closure alerts in TLS 1.2 and I like to understand why we
> need additional text for NETCONF over TLS.


I think we should correct that. What about adopting the text of section
4.4 of syslog-tls
(http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt).

   "A TLS client MUST close the associated TLS connection if the
   connection is not expected to deliver any NETCONF messages later.  It
   MUST send a TLS close_notify alert before closing the connection.  A
   client MAY choose to not wait for the server's close_notify alert and
   simply close the connection, thus generating an incomplete close on
   the seFrom [e-mail]  Sat Sep 27 07:16:16 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 DA1843A6405;
	Sat, 27 Sep 2008 07:16:16 -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 3FFA93A6405
	for <[e-mail]>; Sat, 27 Sep 2008 07:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Level: 
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.376, 
	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 pFWutJxtFJn9 for <[e-mail]>;
	Sat, 27 Sep 2008 07:16:15 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 439A13A63D2
	for <[e-mail]>; Sat, 27 Sep 2008 07:16:14 -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 m8REoSiC557164;
	Sat, 27 Sep 2008 15:50:28 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Sat, 27 Sep 2008 15:49:33 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]><[e-mail]>
	<[e-mail]>
Date: Sat, 27 Sep 2008 15:49:33 +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]); Sat, 27 Sep 2008 15:50:31 +0100 (WEST)
Cc: =?utf-8?Q?=C2?= <[e-mail]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?q?conf-t__ls-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]

> On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote:
>> Hi,
>> in section 2, it says,
>> "The other party MUST respond with a close_notify alert of
>> its own and close down the connection immediately, discarding any
>> pending writes"
>> I wanna ask why immediately instead of sending pening writes before
>> close down the connection.
>
> And I like to add whether it is normal practice that the TLS teardown
> procedure is application protocol specific. RFC 5246 section 7.2.1
> discusses closure alerts in TLS 1.2 and I like to understand why we
> need additional text for NETCONF over TLS.


I think we should correct that. What about adopting the text of section
4.4 of syslog-tls
(http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt).

   "A TLS client MUST close the associated TLS connection if the
   connection is not expected to deliver any NETCONF messages later.  It
   MUST send a TLS close_notify alert before closing the connection.  A
   client MAY choose to not wait for the server's close_notify alert and
   simply close the connection, thus generating an incomplete close on
   rver side.  Once the server gets a close_notify from the
   client, it MUST reply with a close_notify unless it becomes aware
   that the connection has already been closed by the 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 server MAY close the
   connection.  The server MUST attempt to initiate an exchange of
   close_notify alerts with the client before closing the connection.
   Servers that are unprepared to receive any more data MAY close the
   connection after sending the close_notify alert, thus generating an
   incomplete close on the client side.  When the client has received
   the close_notify alert from the server and still has pending data to
   send, it SHOULD send the pending data before sending the close_notify
   alert."

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


the server side.  Once the server gets a close_notify from the
   client, it MUST reply with a close_notify unless it becomes aware
   that the connection has already been closed by the 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 server MAY close the
   connection.  The server MUST attempt to initiate an exchange of
   close_notify alerts with the client before closing the connection.
   Servers that are unprepared to receive any more data MAY close the
   connection after sending the close_notify alert, thus generating an
   incomplete close on the client side.  When the client has received
   the close_notify alert from the server and still has pending data to
   send, it SHOULD send the pending data before sending the close_notify
   alert."

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