transport mappings capability

[Andy Bierman <ietf@andybierman.com>]

Hi,


Remind me again how a manager figures out which optional
transport mappings are supported?

A client connects to NETCONF-over-SSH on the new mandatory
NETCONF-over-SSH port -- that much I understand.  Except
for trial and error, how does the client know
if the agent supports BEEP, SOAP, and on which
ports.  What if NETCONF over SOAP/HTTPS is available
on port 443?  What about NETCONF over SSH on port 23?

Do we need a 'transport' capability similar to our 'url' capability?

====================================

Capability: transport

Purpose: Describes the transport mappings supported by the agent

urn:ietf:params:netconf:capability:transport:1.0?
              protocols={ssh,ssh:23,beep,soap,soap:443}

Key: <prot> == protocol on the default NETCONF port for that protocol
    <prot>:<num> == protocol on the specified port number

The capability 'protocols={ssh}' is the default, and therefore not required
to be present if no other transport mappings are supported.

Affected/new operations: none/none

=====================================

IMO, the whole point of this programmatic interface thing
is efficient, deterministic exchanges between the manager and agent.


Andy


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