[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transport mappings capability

Sharon Chisholm wrote:

hi

It's a bit of a chicken and an egg issues. If I can talk to you, I know
how to talk to you. If I can't talk to you, I can't learn how to talk to
you. A well-known port would certainly be helpful for this case.



We will have that.


I guess your capability proposal is to solve the problem where I might
prefer to talk to you using another transport protocol. Having a
capability wouldn't hurt in this case, but this is more of a corner case
then being able to talk in the first place.


There is no corner case.   It is just a need to discover all the
mappings that an agent will support.

A manager can always talk to an agent over the default mapping (SSH).
The issue is whether a standard capability, standard data model,
or proprietary mechanism be used to find out if any other mappings
are supported. 


Sharon


Andy


-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, March 15, 2006 8:07 PM
To: Netconf (E-mail)
Subject: transport mappings capability


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


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