Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 29 September 2008 10:13 UTC

Return-Path: <netconf-bounces@ietf.org>
X-Original-To: netconf-archive@ietf.org
Delivered-To: ietfarch-netconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B6F3A68CF; Mon, 29 Sep 2008 03:13:35 -0700 (PDT)
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849A43A67EA for <netconf@core3.amsl.com>; Mon, 29 Sep 2008 03:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 hx6Wn8vyM9En for <netconf@core3.amsl.com>; Mon, 29 Sep 2008 03:13:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 364863A6806 for <netconf@ietf.org>; Mon, 29 Sep 2008 03:13:33 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52FD0C000D; Mon, 29 Sep 2008 12:13:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KkxkKlEVgHfe; Mon, 29 Sep 2008 12:13:40 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CAA6C0003; Mon, 29 Sep 2008 12:13:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5FD9F7D49A8; Mon, 29 Sep 2008 12:13:40 +0200 (CEST)
Date: Mon, 29 Sep 2008 12:13:40 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: badra@isima.fr
Message-ID: <20080929101340.GC22657@elstar.local>
Mail-Followup-To: badra@isima.fr, fanhuaxiang? 90002624? <washam.fan@huawei.com>, ? <netconf@ietf.org>
References: <fa17895d38c09.38c09fa17895d@huawei.com> <54592.88.164.98.77.1222597371.squirrel@www.isima.fr>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: ? <netconf@ietf.org>
Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netconf-bounces@ietf.org
Errors-To: netconf-bounces@ietf.org

On Sun, Sep 28, 2008 at 12:22:51PM +0200, badra@isima.fr wrote:

> Here is the last text we agree on.
> Dear Juergen, based on Washam's comments, I think we need to keep such a
> text even if TLS describes this alert.
> 
> 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.
> 
>    A NETCONF peer MUST close the associated TLS connection if the
>    connection is not expected to deliver any rpc operation or when no data
>    is received from a connection for a long time, where the application
>    decides what "long" means.

I don't really see the value of this sentence. Essentially the text
says "an application MUST close the TLS connection if the application
believes the TLS connection is not used anymore" - something rather
obvious and I am not sure an explicit MUST is needed.

>    The NETCONF peer MUST send a TLS close_notify alert before
>    closing the connection.

But I think you can't rely on being able to do this in all cases.
Perhaps this should be a SHOULD instead of a MUST.

>    A sender's
>    close_notify MAY choose to not wait for the receiver's close_notify
>    alert and simply close the connection, thus generating an incomplete
>    close on the receiver's close_notify side.  Once the receiver gets a
>    close_notify from the sender's close_notify, it MUST reply with a
>    close_notify unless it becomes aware that the connection has already
>    been closed by the sender (e.g., the closure was indicated by TCP). 

See above - I assume a SHOULD is more appropriate than a MUST.

>    In the case the receiver still has pending data to send, it
>    SHOULD send the pending data before sending the close_notify
>    alert.

Here I agree with the SHOULD. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf