[HN Gopher] Simple as in SMTP
___________________________________________________________________
Simple as in SMTP
Author : zdw
Score : 28 points
Date : 2021-05-02 14:02 UTC (9 hours ago)
(HTM) web link (computer.rip)
(TXT) w3m dump (computer.rip)
| chousuke wrote:
| Are there any sane solutions for managing lots of MIBs? In my
| experience the largest pain with SNMP comes from the fact that
| vendors usually provide their MIBs as a single huge pile of junk
| containing some random version of all the dependencies as well,
| with completely random file naming conventions.
|
| This means that trying to use two vendors' MIBs together with eg.
| snmptrapd basically leads to undefined behaviour when translating
| traps. I don't know if there any way to actually tell which
| definitions will take precedence or whether the definition is
| correct.
|
| It also doesn't help that often the trap's translation is just as
| cryptic as the bare OID.
| networkimprov wrote:
| This is about SNMP, and says nothing about SMTP.
| iso1210 wrote:
| The link does say
|
| >>> 2021-05-01 simple as in smtp
|
| I suspect the idea is that neither smtp nor snmp are simple
| when you dig down, despite the name.
|
| And I'd agree with the article, mibs can be maddening
|
| And for snmpv3:
|
| "if you are using SNMPv3 where the authentication and
| configuration can be amazingly, maddeningly complex for some
| vendors."
|
| Indeed
| wpietri wrote:
| That could be, but I'd rather they made the case. When SMTP
| came out, it was indeed very simple. In college in the 1980s,
| I could send email just by doing something like:
| % telnet mail.umich.edu 25 MAIL FROM:
| <william@umich.edu> RCPT TO: <joe.blow@umich.edu>
| DATA From: William Pietri <william@umich.edu>
| To: My Skeptical Friend <joe.blow@umich.edu> Subject:
| Who needs a mail client? You can send email
| without a mail client! .
|
| It's harder now, because spammers. But to me it's amazing
| that something like has been working for nearly 40 years. For
| perspective, it came out the same year as the Commodore 64.
|
| The curious can read the inital RFC:
| https://tools.ietf.org/html/rfc821
| networkimprov wrote:
| > because spammers
|
| And because cybercrime, which is now doing staggering
| damage, much of it initiated via SMTP.
|
| SMTP was designed when the Internet's topology and
| population were vastly different, and we desperately need
| to replace it, e.g. with TMTP from the "mnm" open source
| project:
|
| https://mnmnotmail.org/
| sigg3 wrote:
| Fun fun fun!
|
| Well-written and informative.
| imperialdrive wrote:
| Did author really get the tagline wrong?
| lucb1e wrote:
| Either that, or it's some joke about SMTP and SNMP both having
| quite a bit of complexity for both being the Simple [Something]
| Protocol.
| soneil wrote:
| The common joke is that "simple network management protocol"
| is four lies, so I'd assume you're in the right direction.
| foreigner wrote:
| In my experience if the designers of a technology felt the need
| to put the words "simple" or "lightweight" in to the name, it is
| usually the opposite.
| varispeed wrote:
| Also because they made it, it may feel "simple" to them and
| it's "lightweight" because they cut corners...
| throw0101a wrote:
| LDAP is lightweight compared to X.500's DAP. SMTP is simple
| (and lightweight) compared to X.400.
| janci wrote:
| Some vendors can not get even the simple SNMP right and will send
| OIDs in wrong order in WALK, causing a standard-observing SNMP
| client to prematurely end a subtree walk or to loop forever.
|
| And the SNMP is mostly read-only, usually only basic functions
| can be controlled (such as interface enable/disa le) but more
| complex configuration can be only read (vlans, firewall rules,
| etc.)
|
| So really the SNMP support in datasheet means nothing.
| soneil wrote:
| My favourite is systems that exit a walk early, leaving
| subtrees you'll never find unless you start the walk
| specifically within that tree.
___________________________________________________________________
(page generated 2021-05-02 23:02 UTC)