[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: How should we deal with experimental netconf work?
HI,
To me, it looks like you are oversimplifying the issue.
That is, it appears that you are turning this into a
development tools issue. And note, many tools do make
this a trival operation.
However, from my view, it is a deployment and versioning
issue. That is, SNMP agents and SNMP management applications
are in all but the most trivial case developed independantly
using different developers with different timelines, and
different motivations. The motivators is key. A device
vendor supports SNMP agents in their devices so that
both their management apps can manage the device and
so that management apps developed by other can manage
the device. These others include generic SNMP tools
such as MIB browsers, and poller/reporters (such as
MRTG), and application specific tools (such as AdventNet's
WiFi manager
(http://manageengine.adventnet.com/products/wifi-manager/index.html))
However, if the company is not an independent
network management application developer, then there is
little motivation to add support for devices for
other companies.
Connecting the dots....
An SNMP agent is developed that uses an experimental or
proprietary MIB objects.
An matching management app (using those objects) is developed.
Both the device and app are fielded and provide
some useful functionality.
Now, the experimental MIB objects are re-specified in a standards
track document with the OIDs changed (plus some possible changes).
There may be some motivation for the agent to be updated
to support both the old and new objects (so that device
can be managed by 3rd party management apps), but there is
little motivation for the management app to be updated.
Depending on scope of the "small changes" that are done
in addition to the OID changes, the cost might be quite
high. Depending on the SNMP agent technology (and possibly
tool kit), it might be expensive from the code size
to support both old and new OIDs for the objects.
I see these same motivations and costs with XML encoded
data. So, I believe it will continue to be an issue of
fielding a product, and then applying an incompatable
change without any delivered benefit.
Regards,
/david t. perkins
On Thu, 26 Jan 2006, Sharon Chisholm wrote:
> hi
>
> I think you would just have to switch the namespace when it moved. I
> think that makes it a bit cleaner than with SNMP, but still potentially
> a problem.
>
> Sharon
>
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Tom Petch
> Sent: Thursday, January 26, 2006 12:24 PM
> To: Andy Bierman; Netconf (E-mail)
> Subject: Re: How should we deal with experimental netconf work?
>
>
> The trick that SNMP failed to solve was how to amend all the OIDs in the
> debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without
> introducing any errors. I see this as the reason for the lack of use of
> SNMP experimental.
>
> So the question is, can this problem be avoided in XML?
>
> Tom Petch
>
> ----- Original Message -----
> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Wednesday, January 25, 2006 9:15 PM
> Subject: How should we deal with experimental netconf work?
>
>
> > Hi,
> >
> > I have an idea that may help those in the WG that believe standards
> > based on real-world solutions are not that important. I have to clear
> > it with Simon and the ADs first, but here goes...
> >
> > People with ideas for extensions should (hopefully) implement them,
> > write them up in an Internet Draft, and propose them to the WG.
> >
> > We have a "netconf base" URI.
> > We can also have a "netconf experimental" URI.
> > (Yes, I know SMI has this already. We need it for the same reason.)
> >
> > The WG can then decide on new proposals:
> > 1) no thanks
> > 2) come back later with more details
> > 3) develop it as Experimental first (decide on standard later)
> > 4) charter it and develop it as a Proposed Standard
> >
> > This experimental branch (like in MIBs) would not be stable like a
> > standard, but it is better than a vendor extension. Competitors in the
>
> > same market will be reluctant to implement each other's proprietary
> > extensions, but they will be able to agree in a WG to implement
> > something as a "netconf experimental" extension.
> >
> > The bar for Experimental should be much lower than for Proposed
> > Standard, in terms of initial proposal deployment, WG involvement and
> > IESG review.
> >
> > Comments?
> >
> > 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/>