[ntpwg] NTPv4 MIB Revised Version 1.2

[Heiko Gerstung]

David L. Mills schrieb:
> Heiko,
> 
> I have a really bad feeling about the fate of this mission. You are 
> assuming when something bad happens, badness will be limited to 2147 
> seconds. In my experience, badness happens over a 68-year span. I would 
> never in a heartbeat trust a monitoring scheme that did not reveal the 
> entire space of any variable that might go wrong.
You are free to choose what monitoring scheme suits you. I know a lot of 
people who would have no problems with monitoring a range-limited data 
object and, if this one exceeds a limit (far away from the maximum of 
2147 seconds) have a look at the full range object or use ntpq or 
another mode 6 tool to investigate what's wrong.

> I gather from a philosophical point of design that it would be 
> considered bad to parse the display string. Only believe the actual data 
> representation in whatever format. I gather folks are uncomfortable with 
> blatent kludge like parsing ASCII REALS. I gather this is because their 
> favorite automonitoring tools can't handle that. Maybe there aren't too 
> many services to be monitored that display in floating formats, but NTP 
> certainly does. If monitoring tools can't deal with that, then the tools 
> are defective and somebody will sell new tools that can do that. I can't 
> believe the SNMP agent technology is that archaic and stupid; but, if it 
> is, I have a couple of bridges on my office wall for sale.
Well, I was stunned by that, too. This was the reason I did not even 
think of checking in the RFCs whether REAL is allowed or not. But SNMP 
is that way, I guess that's why they call it "Simple". If they ever 
include floating point values, I vote for changing the name to 
"Sophisticated Network Management Protocol" :-)

> There is a shrill disconnect between the monitoring style of imposing 
> external limits and verifying that the managed article stays within 
> bounds. NTP is not at all like that. The various thresholds are 
> monitored by the program itself - distance threshold, step, stepout, 
> panic, ... there are lots of them. The intent is that the thresholds be 
> set by default and/or configuration/SNMP and the monitored object will 
> observe its own thresholds. Be advised, these thresholds are set in 
> floating format. If this design is believed, the only thing the external 
> agent should care about is a report from the managed object that it is 
> running within bounds or not.

You are correct, it should be no problem to monitor other values to get 
an idea of the health of your NTP server (heck, maybe even "stratum 
level" is sufficient).

> If an external agent needs to know more about the internal workings of 
> NTP, then it must speak the same language; ergo it must understand the 
> same data types. Should the pragmatics of commerce or the nabobs of 
> current principle prevail, I am not on that airplane and do not fly that 
> airline. Accordingly, I have struggled to participate and contribute to 
> the SNMP mission, but I do stand down my rhetoric and will continue to 
> cherish and defend the mode-6 protocol.
Mode-6 protocol is simply not interesting for most network 
administrators in the real world, because it is just another monitoring 
protocol and because their servers, printers, switches, routers and 
coffee machines (that is the real critical point of failure, believe me) 
speak SNMP and they just do not want to add a different monitoring style 
for a couple of NTP servers to their management console.

> I believe a proxy agent, even if an unpopular option, is the only way to 
> provide MIB support no matter what format. I see no credible means for 
> modifying the reference implementation to support the proposed MIB 
> directly.

I agree that a proxy agent is the best solution, because it allows 
people to monitor their current equipment without a major software 
modification. And nobody says that it is forbidden to run such a proxy 
agent on the same machine, using mode 6 to query 127.0.0.1 ..

> Bottom line. SNMP is not suited for and cannot adequately monitor and/or 
> control the NTPv4 implementation.

That is true for you, but I disagree (and I think I am not alone .. :-))

Regards,
Heiko




> Dave
> 
> Heiko Gerstung wrote:
> 
>> Hi, Folks:
>>
>> It seems that we all agree that the floating point values we want to 
>> include in the NTPv4 MIB are represented as ASCII strings 
>> (DisplayString) and we leave it up to the SNMP agent to parse them and 
>> convert them into floating point values. This is already included in 
>> the current MIB revision, but I would like to add a fixed unit/scale 
>> regarding the format of the strings, in order to prevent different 
>> implementations to generate different string formats.
>>
>> Regarding the binary representation of the values in integer format: 
>> From my experience with SNMP I would say that it is much easier to set 
>> up a monitoring tool to check if certain limits are within a given 
>> range than first writing / setting up a string parser and then apply 
>> the range check. I also saw a number of smaller tools that are not 
>> capable of applying a string parser on a data object that was received 
>> by SNMP and I do not think that people who run these tools should be 
>> asked to setup an SNMP proxy agent, because IMHO they are running the 
>> dumb tools in order to keep things simple. Setting up a proxy adds a 
>> new level of complexity that I think they are trying to avoid.
>>
>>
>> I still think that the limit of 2147 seconds is no problem for these 
>> range checks, as their main purpose is to trigger notification (and I 
>> cannot imagine that someone does not want to be notified if her/his 
>> NTP server is sailing away with such an offset). If I want to collect 
>> statistics I could go with the string data object instead.
>>
>> IMHO it is not a problem to deal with the possibility that the string 
>> representation can differ from the integer representation, as long as 
>> this is clearly defined in the MIB.
>>
>> However, if this is something the majority of you guys feels 
>> uncomfortable with or if you see major problems arising caused by 
>> this, I could simply remove those data objects from the MIB and we go 
>> on with strings and nothing else for this kind of data objects.
>>
>> Kind regards,
>> Heiko
>>
>>
>>
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at support.ntp.org
> https://support.ntp.org/mailman/listinfo/ntpwg
> 


-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung at meinberg.de <mailto:heiko.gerstung at meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide