Re: Issue 6.1) SOAP Proxy

[Ted Goddard <ted.goddard@windriver.com>]

The NETCONF/SOAP draft contains the following text:

3.6 Managing Multiple Devices

   When a server is acting as a proxy for multiple devices, the URL for
   the HTTP POST can be used to indicate which device is the target.  It
   may also be desirable to use the HTTP POST URL as a means for
   selecting from multiple virtual devices on a single device.

This idea is only half-formed and it's not fundamental to the
protocol, so I'll remove the text.  Are there basic objections, though?
There are certainly valid uses for having a server aggregate management
connections.  Maybe the idea should be fully-formed and included.

Suggested revision:

3.6 HTTP Proxy Considerations

   NETCONF is a stateful protocol and is incompatible with HTTP proxies.
   To see the incompatibility, consider the following scenario.
   A manager connects to a NETCONF agent via an HTTP proxy, and requests
   a lock.  After a period of time, the proxy closes its connection
   to the agent without notifying the manager.  Subsequent operations
   proceed without the lock as they take place on new connections 
initiated
   by the proxy.  This condition may not be caught until the manager
   attempts to release the lock.

   A further complication is that an HTTP proxy may be "transparent"
   by automatically filtering traffic on port 80.  If such an 
environment
   is believed to be present, it is recommended that HTTPS be used 
rather
   than HTTP, as HTTPS is not vulnerable to proxy interference.

There are other ways to deal with this, however -- my impression
is that there is some desire to remove the idea of "session" from
NETCONF/SOAP, and the above paragraph is compatible with that.
However, if we keep sessions, then an HTTP proxy will appear somewhat
like an unreliable connection -- the proxy may cause you to lose your
lock, but on the next operation the NETCONF agent will notice that
it is requested on an expired session and respond with an error.
With this you should be able to function in an HTTP proxied environment
as long as you handle errors gracefully and work quickly enough to
avoid the proxy timeouts.

Ted.

On Dec 5, 2003, at 10:09 AM, Andy Bierman wrote:

> At 08:36 AM 12/5/2003, Eliot Lear wrote:
> > Andy, this issue is broader.  As Phil pointed out, if people use 
> > SOAP/HTTP transparent proxies could cause all sorts of trouble, 
> > particularly because NETCONF has a session-based view and HTTP does 
> > not.
> >
> > Or is this a different ISSUE?
>
> I was referring to the text in the NETCONF Over SOAP draft
> about proxy mechanisms.  I guess we should have a separate
> issue ID for HTTP proxy issues.
>
>
> > Eliot
>
> Andy
>
>
>
>
> > Andy Bierman wrote:
> > > NETCONF has no proxy; text related to proxy should be removed
> > >
> > > --
> > > 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/>
>
>
> --
> 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/>


--
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/>