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

[[e-mail]]

> 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 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].  TFrom [e-mail]  Sat Sep 27 14:31:24 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 794A83A68D1;
	Sat, 27 Sep 2008 14:31:24 -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 3DCB03A68D1
	for <[e-mail]>; Sat, 27 Sep 2008 14:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.102
X-Spam-Level: 
X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5
	tests=[AWL=-0.719, BAYES_40=-0.185, 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 pSAJbJhT1kpz for <[e-mail]>;
	Sat, 27 Sep 2008 14:31:22 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 33F193A68AA
	for <[e-mail]>; Sat, 27 Sep 2008 14:31:22 -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 m8RMUFeh745650;
	Sat, 27 Sep 2008 23:30:15 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Sat, 27 Sep 2008 23:29:21 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Date: Sat, 27 Sep 2008 23:29:21 +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 23:30:20 +0100 (WEST)
Cc: =?utf-8?Q?=C2?= <[e-mail]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgPz/CoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1u?=
 =?utf-8?q?et_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]

> 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 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
   [RFC524he 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.


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


6].  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.


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