[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: little problem with <close-session>
Hi Eliot,
(2) For TCP-based session-layer protocols, it is (IMO) highly desirable
for the manager to be the one that initiates the TCP-level close, so that
s/manager/agent
the TIME-WAIT state ends-up on the agent side. A manager may manage
a very large number of devices and need to connect to all of those devices
in rapid succession, while it seems less likely that an individual device
will be reconfigured as often.
Think about a meta-command, then.
What is a "meta command"?
I can already do this in the BEEP mapping, and can control which side
disconnects first. But putting that aside, in the case of an attack (which
is what I think you're concerned about), the device is going to close
unauthenticated connections as a defensive mechanism, no matter what
the protocol says.
I am not talking about an attack, I am talking about normal operation.
As you may recall, one of the serious problems with HTTP 1.0 was that it
opened many TCP connections and left the connections in TIME-WAIT
state on the server (because the server would close the connection to
indicate end-of-file). Because there was one server and many, many
clients, the server would eventually run out of resources.
In our protocol, there is likely to be one manager and many, many
agents. Therefore, we need to be careful that any state (such as
TIME-WAT state) that is left behind after a session completes remains
on the agent, not on the manager.
So, it is important that all TCP connection closes are initiated by the
agent, so that the agent will end-up with the TIME-WAIT state. And,
I consider <close-session> to be a good way for the manager to ask
the agent to initiate a close.
Can you explain what problem <close-session> causes?
I don't understand what the existence of <close-session> has to do
with the fact that we don't have the ability for the agent to send
commands to the manager. I understand that the agent might close
the session in mid-session if the agent is shut down, but that will
typically result in a reset and wouldn't be considered normal
operation. It is also possible that an agent or manager will crash
(go away without closing or resetting the session) or that the agent
will become unreachable from the manager (and/or vice versa) due
to network problems that are unrelated to either the manager or
agent... Implementations will need to handle those conditions.
Do you think we need to add text to the base spec explaining
what happens in such abnormal close conditions? I'm not sure this
is needed to write interoperable implementations, but perhaps it
would address your issue of what happens when the agent needs
to close the session?
Margaret
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>