Slashdot Mirror


Goodbye SNMP? Hello, WS-Management

Laoping writes "News.com has a story about a new Web services management specification designed to simplify network administration across a wide range of devices. A bunch of a big tech companies developed it together (Microsoft, Intel, AMD, Dell and Sun). Microsoft will build support for WS-Management into an update to Windows Server, which is due late next year, and in the version of its Microsoft Operations Manager management software due in 2006. The .PDF release, that makes it clear that it is meant to be a Simple Network Management Protocol killer. Now I am all for a replacement for SNMP, but is this the way go?"

8 of 176 comments (clear)

  1. Why is it that every there's something new.... by Anonymous Coward · · Score: 5, Insightful

    The moron submitting the summary says "goodbye [long established and well entrenched technology]". SNMP has been around for a very, very long time. No matter how much better this is, it will not replace SNMP any time soon.

    Read the article about the 32-bit MCUs a few stories down for yet another example.

  2. Goodbye SNMP? Hardly. by cablepHreaK · · Score: 5, Insightful

    SNMP is not going anywhere anytime soon, until the major network players adopt WS-Management (that's if they adopt it at all). Looking at the PDF there are some major players missing, Cisco, Juniper, 3Com, HP, to name a few.

  3. but the important question is ... by Triumph+The+Insult+C · · Score: 4, Insightful

    will it be encumbered by patents? looking at the contributors, my guess is yes

    snmp v3 works perfectly fine as it is. let's leave well enough alone

    but, this will probably work out well for intel ... i mean, you'll probably need (by the time it comes out) at least a 3.8Ghz P4 and 2G of RAM

    --
    vodka, straight up, thank you!
    1. Re:but the important question is ... by justins · · Score: 5, Insightful
      snmp v3 works perfectly fine as it is.

      Are you fucking kidding?

      but, this will probably work out well for intel ... i mean, you'll probably need (by the time it comes out) at least a 3.8Ghz P4 and 2G of RAM

      What an amazingly "Score: 5, Insightful" observation. It's almost enough to make a person believe that Intel doesn't sell more chips for networking and embedded applications than they do desktop CPUs. Which they do.
      --
      Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
  4. Cisco? Nortel? by Linegod · · Score: 5, Insightful

    If I don't see Cisco and/or Nortel on the list, it's not going to replace SNMP anytime soon. Correction: _ever_.

    .

    --
    -- I care not for your foolish signatures.
  5. Re:wonder by NicolaiBSD · · Score: 4, Insightful

    There's no real incentive to move to IPv6, at least not in the western world, as there's plenty of IPv4 address space left. Apart from that there's also the perceived complexity of IPv6 (long hex numbers, so it must be more complicated than shorter decimal numbers).

    If you've worked with SNMP, you know that it is a technically solid solution - low on resources, fast. However, SNMP _is_ complex. Finding OIDs in large MIBs, secure configuration, interpreting data are mostly difficult.

    I give a technically sound, industry standard and less complex alternative for SNMP a good chance for quick adoptation.

  6. Re:Goodbye SNMP? Hardly. by Alan+Cox · · Score: 4, Insightful

    Also on the folks churning out billions of tiny little devices. If you've only got 16K of RAM TCP is hard work let along management services while UDP is doable properly on a microcontroller.

  7. snmp v3... by bani · · Score: 5, Insightful

    snmp v3 works perfectly fine as it is. let's leave well enough alone

    considering most vendors are still using v1 or v2, that should be 'lets leave snmp v3 alone' :)

    to be perfectly honest, SNMP is anything but simple. the only thing simple about it is the protocol itself. it then got buried under avalanches of proprietary MIBs, all partially overlapping yet all mutually incompatible. some only partially documented (or not documented at all). not only that, the insistence of vendors using funky proprietary data types (or worse, strings) when existing datatypes would work perfectly fine.

    what was needed imo was a MIB guideline and 'retarded implementation' verification. to ensure vendors didn't create obfuscated and spaghettified MIBs.