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

Re: transport mappings capability

Rob Enns wrote:
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. 

I wonder if it would be used though. Would a manager connect to
an agent over SSH, discover that the agent supports SOAP, and go
back to use SOAP? Most deployments would know the connection
method by fiat.


The first decision is "should there be a standard mechanism for a manager to
discover the transport mappings that an agent is configured to use?"

If yes, then the next decision is "what mechanism?"

I think a standard data model is better than a capability.
Since we don't have any standard data models yet,
I suggested a capability, but a data model is the right choice.

This is really just "more configuration data" in the end.
A manager should be interested in the enabled transport mappings.
What if non-secure mappings (like SOAP/HTTP) are enabled
but should not be?  What if the configurable BEEP port has been changed
by one manager and now another manager can't talk to the agent over BEEP?

One could argue that since there are plenty of standard configuration
data models
more important than this one that don't exist either, there is little
urgency to
fix this particular problem.   (One would be right ;-)


Rob


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