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

Hi,
> 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.
wouldn't the last sentence contradict what specified in TLS rfc?
> 
> 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
> 
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf