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

[Juergen Schoenwaelder <[e-mail]>]

On Sat, Sep 27, 2008 at 03:49:33PM +0200, [e-mail] wrote:
> > 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 syslogFrom [e-mail]  Sat Sep 27 08:52:32 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 2AA113A68F0;
	Sat, 27 Sep 2008 08:52:32 -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 69D1F3A68F0
	for <[e-mail]>; Sat, 27 Sep 2008 08:52:31 -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 dVtkeEF3mS3M for <[e-mail]>;
	Sat, 27 Sep 2008 08:52:30 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de
	[212.201.44.23])
	by core3.amsl.com (Postfix) with ESMTP id 9A9BD3A68C8
	for <[e-mail]>; Sat, 27 Sep 2008 08:52:29 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1C6C0054;
	Sat, 27 Sep 2008 17:41:26 +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 z7TUBmmkewTo; Sat, 27 Sep 2008 17:41:19 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id CAB40C0035;
	Sat, 27 Sep 2008 17:41:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
	id B18717BB0C4; Sat, 27 Sep 2008 17:41:19 +0200 (CEST)
Date: Sat, 27 Sep 2008 17:41:19 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail],
	fanhuaxiang? 90002624? <[e-mail]>, ? <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: ? <[e-mail]>
Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt
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]

On Sat, Sep 27, 2008 at 03:49:33PM +0200, [e-mail] wrote:
> > 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 -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 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."

Can someone explain to me _why_ all this detail is needed? The SSH
transport mapping does not spell how how the SSH teardown is done.
So why do we need to be that specific with TLS?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf


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 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."

Can someone explain to me _why_ all this detail is needed? The SSH
transport mapping does not spell how how the SSH teardown is done.
So why do we need to be that specific with TLS?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf