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

Hi,

FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review)
has updated that section to make a clearer distinction between the TLS
actions and the application actions. Transport sender and transport
receiver refer to syslog application fuctionality, and they coordinate
the closure actions. 

   A transport sender MUST close the associated TLS connection if the
   connection is not expected to deliver any syslog messages later.
It
   MUST send a TLS close_notify alert before closing the connection.
A
   transport sender (TLS client) MAY choose to not wait for the
   transport receiver's close_notify alert and simply close the
   connection, thus generating an incomplete close on the transport
   receiver (TLS server) side.  Once the transport receiver gets a
   close_notify from the transport sender, it MUST reply with a
   close_notify unless it becomes aware that the connection has
already
   been closed by the transport sender (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 transport receiver MAY
   close the connection.  The transport receiver (TLS server) MUST
   attempt to initiate an exchange of close_notify alerts with the
   transport sender before closing the connection.  Transport
receivers
   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 transport sender side.  When the transport sender (TLS
   client) has received the close_notify alert from the transport
   receiver and still has pending data to send, it SHOULD send the
   pending data before sending the close_notify alert.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

> -----Original Message-----
> From: netconf-bounces@ietf.org 
> [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr
> Sent: Saturday, September 27, 2008 9:50 AM
> To: j.schoenwaelder@jacobs-university.de
> Cc: Â
> Subject: [Netconf] Re:  WGLC for draft-ietf-netconf-t ls-04.txt
> 
> > 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 syslog-tls
> (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpo
> rt-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."
> 
> Best regards,
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf