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

From: [email-masked]
Date: Mon, 6 Oct 2008 20:18:28 +0200 (CEST)

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 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?
Best regards,
Badra
_______From [email-masked]  Mon Oct  6 11:20:02 2008
Date: Mon, 6 Oct 2008 20:18:28 +0200 (CEST)
From: [email-masked]
To: [email-masked]
Importance: Normal
Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection Closure
Sender: [email-masked]

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 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?
Best regards,
Badra
_____________________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

__________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 18 Oct 2008 19:46:43 -0700

Hi -

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 06, 2008 11:18 AM
>   From [email-masked]  Sat Oct 18 19:44:54 2008
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Date: Sat, 18 Oct 2008 19:46:43 -0700
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt: Connection
	Closure
Sender: [email-masked]

Hi -

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 06, 2008 11:18 AM
>    a clo a close_notify unless it becomes aware that the connection has already
...

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

se_notify unless it becomes aware that the connection has already
>    alert, thus generating an incomplete close on the close_notify's
...

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Mohamad Badra" <[email-masked]>
Date: Sun, 19 Oct 2008 12:54:18 +0200 (CEST)

Dear Randy,

>>    (NETCONF agent) close_notify alert and simply cFrom [email-masked]  Sun Oct 19 03:53:26 2008
Date: Sun, 19 Oct 2008 12:54:18 +0200 (CEST)
From: "Mohamad Badra" <[email-masked]>
To: =?utf-8?Q?Randy=C2_Presuhn=C2?= <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?b?Y29uZi10UmU6wqDCoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRjb25mLXRs?=
 =?utf-8?q?s-04=2Etxt=3A=C2=A0ConnectionClosure?=
Reply-To: [email-masked]
Sender: [email-masked]

Dear Randy,

> connection which is "not expected to deliver any rpc operation later" ?

I can share your point of view (Version -04 has a quite different text).
But during WGLC discussion, we agreed to adopt the same text used by
syslog-tls regarding the closure. Note that this text [1] has been
approved by IESG and some WG members have recommended using the same
syslog-tls document's language within netconf-tls.

[1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8

Best regards,
Badra

lose the connection,
> connection which is "not expected to deliver any rpc operation later" ?

I can share your point of view (Version -04 has a quite different text).
But during WGLC discussion, we agreed to adopt the same text used by
syslog-tls regarding the closure. Note that this text [1] has been
approved by IESG and some WG members have recommended using the same
syslog-tls document's language within netconf-tls.

[1] http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14#page-8

Best regards,
Badra