Re: direction of connection

[Simon Leinen <simon@limmat.switch.ch>]

Kent Watsen writes:
> I'm concerned about the direction of the connection.  The current
> spec implies that the device only expects inbound connections -
> section 1.1 states that device==server and app==client; and section
> 2.1 doesn't clarify.

In this context, "client" and "server" should merely be read as roles
in the high-level NETCONF protocol.  This doesn't restrict which side
may initiate the underlying transport connection(s).

This entire business is a matter of the underlying ("substrate")
protocol.  We have several proposed substrates:

draft-ietf-netconf-beep-00.txt
draft-ietf-netconf-soap-00.txt
draft-ietf-netconf-ssh-00.txt

The BEEP and SSH mappings state very clearly that the connection can
be initiated either by the manager (NETCONF client) or by the managed
device (NETCONF server).

The SOAP mapping draft also discusses this, but states that
server-initiated connections are hard to do with HTTP, which SOAP
usually runs on top of.

> I believe that the device should be able to initiate the connection
> to the app (i.e. an NMS) as it:

> 1)       enables the manageability of devices behind a Port NAT 
> 2)       enables the device to manage failover (when NMS can't)
> 3)       enables the device to not have an open port (for stealth mode)

> Has this already been considered? 

Yes, see the substrate-mapping drafts
(draft-ietf-netconf-{beep,soap,ssh}).

>    - I didn't see anything in the mailing list archive...

Well it did come up a few times on the list and also in meetings - I
find it mentioned in

http://ops.ietf.org/lists/netconf/netconf.2002/msg00200.html

for instance.

Regards,
-- 
Simon.

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