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

["Mohamad Badra" <[e-mail]>]

Dear Randy,

> Hi -
>
>> From: <[e-mail]>
>> To: <[e-mail]>
>> Sent: Monday, October 06, 2008 11:18 AM
>> Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection
>> Closure
>>
>> Dear all,
>>
>> Below is a new tentative to agree on the text related to the Section
>> 'Connection Closure'.  The text is much closed to Section 4.4 of
>> draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both
>> the agent and the manager may send data.
>>
>>    A TLS client (NETCONF manager) MUST close the associated TLS
>> connection
>>    if the connection is not expected to deliver any rpc operation
>>    later.  It MUST send a TLS close_notify alert before closing the
>>    connection.  The TLS client MAY choose to not wait for the TLS server
>>    (NETCONF agent) close_notify alert and simply cFrom [e-mail]  Sun Oct 19 03:53:26 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 C0F3D3A69C5;
	Sun, 19 Oct 2008 03:53:26 -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 1CF383A68B7
	for <[e-mail]>; Sun, 19 Oct 2008 03:53:26 -0700 (PDT)
X-Quarantine-ID: <q+CScD4HeGY7>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): Subject:
	...etconf-t?=\n =?utf-8?Q?Re:\302\240[Netconf]\302\240WGL[...]
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level: 
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5
	tests=[AWL=-0.448, BAYES_00=-2.599, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152,
	SUBJ_ILLEGAL_CHARS=1.586]
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 q+CScD4HeGY7 for <[e-mail]>;
	Sun, 19 Oct 2008 03:53:25 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 0707F3A69C5
	for <[e-mail]>; Sun, 19 Oct 2008 03:53:24 -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 m9JBsQDk880684;
	Sun, 19 Oct 2008 12:54:26 +0100
Received: from 88.175.65.115 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Sun, 19 Oct 2008 12:54:18 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <000401c93194$ecc4a180$6801a8c0@oemcomputer>
References: <[e-mail]>
	<000401c93194$ecc4a180$6801a8c0@oemcomputer>
Date: Sun, 19 Oct 2008 12:54:18 +0200 (CEST)
From: "Mohamad Badra" <[e-mail]>
To: =?utf-8?Q?Randy=C2_Presuhn=C2?= <[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]); Sun, 19 Oct 2008 12:54:28 +0100 (WEST)
Cc: [e-mail]
Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?b?Y29uZi10UmU6wqDCoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRjb25mLXRs?=
 =?utf-8?q?s-04=2Etxt=3A=C2=A0ConnectionClosure?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
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]

Dear Randy,

> Hi -
>
>> From: <[e-mail]>
>> To: <[e-mail]>
>> Sent: Monday, October 06, 2008 11:18 AM
>> Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection
>> Closure
>>
>> Dear all,
>>
>> Below is a new tentative to agree on the text related to the Section
>> 'Connection Closure'.  The text is much closed to Section 4.4 of
>> draft-ietf-syslog-transport-tls-14 with one exception; in Netconf, both
>> the agent and the manager may send data.
>>
>>    A TLS client (NETCONF manager) MUST close the associated TLS
>> connection
>>    if the connection is not expected to deliver any rpc operation
>>    later.  It MUST send a TLS close_notify alert before closing the
>>    connection.  The TLS client MAY choose to not wait for the TLS server
>>    (NETCONF agent) close_notify alert and simply close the connection,
>>    thus generating an incomplete close on the TLS server side.  Once the
>>    TLS server gets a close_notify from the TLS client, it MUST reply
>> with
>>    a close_notify unless it becomes aware that the connection has
>> already
>>    been closed by the TLS 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 NETCONF peer MAY close the
>>    connection.  The NETCONF peer MUST attempt to initiate an exchange of
>>    close_notify alerts with the other NETCONF peer before closing the
>>    connection.  The close_notify's sender that is unprepared to receive
>>    any more data MAY close the connection after sending the close_notify
>>    alert, thus generating an incomplete close on the close_notify's
>>    receiver side.
>>
>> Comments?
> ...
>
> RFC 2119 says "Imperatives of the type defined in this memo must
> be used with care and sparingly.  In particular, they MUST only be
> used where it is actually required for interoperation or to limit
> behavior which has potential for causing harm...."  In practice, my
> experience has been that "MUST" has been used in cases where
> things would break or not interoperate, and "SHOULD" has been
> used regarding questions of sound operational practice.
>
>>From that perspective, some of the "MUSTs" above sound like
> they really should be "SHOULDs".  For example, will systems fail
> to interoperate or otherwise break if a client fails to close a
> connection which is "not expected to deliver any rpc operation later" ?

I can share your point of view (Version -04 has a quite different text).
But during WGLC discussion, we agreed to adopt the same text used by
syslog-tls regarding the closure. Note that this text [1] has been
approved by IESG and some WG members have recommended using the same
syslog-tls document's language within netconf-tls.

[1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8

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


lose the connection,
>>    thus generating an incomplete close on the TLS server side.  Once the
>>    TLS server gets a close_notify from the TLS client, it MUST reply
>> with
>>    a close_notify unless it becomes aware that the connection has
>> already
>>    been closed by the TLS 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 NETCONF peer MAY close the
>>    connection.  The NETCONF peer MUST attempt to initiate an exchange of
>>    close_notify alerts with the other NETCONF peer before closing the
>>    connection.  The close_notify's sender that is unprepared to receive
>>    any more data MAY close the connection after sending the close_notify
>>    alert, thus generating an incomplete close on the close_notify's
>>    receiver side.
>>
>> Comments?
> ...
>
> RFC 2119 says "Imperatives of the type defined in this memo must
> be used with care and sparingly.  In particular, they MUST only be
> used where it is actually required for interoperation or to limit
> behavior which has potential for causing harm...."  In practice, my
> experience has been that "MUST" has been used in cases where
> things would break or not interoperate, and "SHOULD" has been
> used regarding questions of sound operational practice.
>
>>From that perspective, some of the "MUSTs" above sound like
> they really should be "SHOULDs".  For example, will systems fail
> to interoperate or otherwise break if a client fails to close a
> connection which is "not expected to deliver any rpc operation later" ?

I can share your point of view (Version -04 has a quite different text).
But during WGLC discussion, we agreed to adopt the same text used by
syslog-tls regarding the closure. Note that this text [1] has been
approved by IESG and some WG members have recommended using the same
syslog-tls document's language within netconf-tls.

[1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8

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