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. wonder by COMON$ · · Score: 5, Funny

    hmmm, I wonder if this will catch on as quickly as IPv6 has.....

    --
    CS: It is all sink or swim...oh and did I mention there are sharks in that water?
  2. 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.

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

  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. but... but... by Anonymous Coward · · Score: 5, Interesting

    The real power of snmp is what you can achieve through scripting it - queries and updates etc.

    That becomes nigh-on impossible with this WS-Management craziness.

    Typical Microsoft - always thinking there is some pleb click-clicking away.

    Imagine you have to change some rmon threshold on 400+ devices, or integrate this with the corporate asset database.
    Now you get the picture.

  6. Re:I'm not sold by nightfire-unique · · Score: 5, Informative
    I don't mean to pooh pooh this idea just because it's somewhat Windows specific but the only real advantage I see to this over snmp is that the delivery modes are more sophisticated and the data can be organized hierarchally.

    The SNMP MIB tree is hierarchical. For example, the "version" parameter of NET-SNMP can be found by querying:

    ucdavis.version.versionTag

    Furthermore, these names have corresponding OID numbers, which are universally unique.

    So why not just add builtin event notification to snmp?

    What, like SNMP traps?

    Come on.. this stuff ain't new. :)

    --
    A government is a body of people notably ungoverned - AC
  7. 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
  8. 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.