Subject: RE: transport mappings capability

From: "Rob Enns" <[email-masked]>
Date: Thu, 16 Mar 2006 17:33:43 -0800

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

Rob

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Mar 2006 18:11:43 -0800

> back to use SOAP? Most deployments would know the connection

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