Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure

["Randy Presuhn" <[e-mail]>]

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
>   From [e-mail]  Sat Oct 18 19:44:54 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 44F7E3A69FE;
	Sat, 18 Oct 2008 19:44:54 -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 81E6F3A6A08
	for <[e-mail]>; Sat, 18 Oct 2008 19:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5
	tests=[AWL=-1.207, BAYES_40=-0.185]
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 2rNOJq7Y5sx4 for <[e-mail]>;
	Sat, 18 Oct 2008 19:44:51 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net
	(elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69])
	by core3.amsl.com (Postfix) with ESMTP id 9867F3A69FE
	for <[e-mail]>; Sat, 18 Oct 2008 19:44:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=dk20050327; d=mindspring.com;
	b=FcdmvUCFZFw0f26ilXFP9R7ls5LhMT227uV2fgemt45bWJ5TeW9y6AbXzzxoicwx;
	h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [69.3.25.176] (helo=oemcomputer)
	by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67)
	(envelope-from <[e-mail]>) id 1KrOIp-0002P9-BW
	for [e-mail]; Sat, 18 Oct 2008 22:45:59 -0400
Message-ID: <000401c93194$ecc4a180$6801a8c0@oemcomputer>
From: "Randy Presuhn" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 18 Oct 2008 19:46:43 -0700
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4d93c93d116ec7c6485b6a7e28594e64f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 69.3.25.176
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection
	Closure
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 -

> 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 clo 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" ?

Randy

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


se_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" ?

Randy

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