[ntpwg] NTPv4 MIB Revised Version 1.2

Tue Jan 24 18:09:08 UTC 2006

Guys,

I've been (along with many others) watching NTP performance for 25 
years. There have been many times when the offset did exceed 2147 
seconds and I really and truly needed to know about it and indeed the 
magnitude was very significant.

I don't understand the design principles of a monitoring system that 
would hide the magnitude indication if greater than any fixed amount. 
That's exactly whey the NTPv4 implementation uses floating double. In 
any case, offset magnitudes are valid over the range from 68 years in 
the past to 68 years in the future. It should be possible to reveal the 
full range in any monitoring protocol.

Your comment about the tattletale string revealing the full range but 
the integer-mapped value only a subrange is fascinating. Rather than the 
managed object produce both the tattletale and integer representation, 
even if they disagree, does not seem a good idea at all and suggests an 
alternate interpretation. Let the managed object produce whatever 
tattletale string pertains to the variables and the SNMP agent call on a 
crafted parser which can distill such parameters as needed. This may not 
be a popular idea, but the alternative is every managed object has to 
shoehorn meaningful data into unfriendly data types.

My agenda for a ntpq-MIB agent is that we did it before and can do it 
now and without major changes in ntpd, which frankly is not going to 
happen anytime soon. The major benefit is that the experience gained 
could very likely lead to needed improvements in SNMP itself.

Is it the expectation of this group that the MIB apply only to NTPv4? 
Does this isolate NTPv3?

Dave

Heiko Gerstung wrote:

> Kevin Golder schrieb:
>
>> Heiko,
>>
>> If you revert back to the method in the first rev, is it acceptable to
>> limit the range of offsets you can now represent?  Does anyone have a
>> problem with only being able to represent an offset of about 2147
>> seconds if using an Integer32 with microsecond resolution?
>
>
> Would be acceptable to me to have such a maximum offset. The real 
> value would be accessible in string format and the main usage of the 
> numeric representation (easy checking of limits) would be OK, because 
> if you do not want your SNMP agent to throw you out of the bed when it 
> is sailing beyond an offset of 2147 seconds, you can just forget about 
> it :-)
>
>> The only other way of presenting a float number correctly in a MIB is to
>> use three separate variables to represent the one value, a mantissa,
>> base, and exponent.
>
>
> For a Management application I would prefer having flat values, which 
> I can check against limits with simple rules like "if greater than 
> 10000" and without having to calculate the value.
>
> So, me, myself and I could live with this limitation. I would define 
> the offset values to stick with the minimum/maximum value if the 
> offset is beyond -/- 2147 seconds. The string representation should 
> always represent the current offset value and if someone has to deal 
> with offsets greater than the limit, she/he at least could use the 
> string representation.
>
> Regards,
> Heiko
>
>
>
>
>>
>> Regards,
>> Kevin
>> -----Original Message-----
>> From: Heiko Gerstung [mailto:heiko.gerstung at meinberg.de] Sent: 
>> Tuesday, January 24, 2006 10:12 AM
>> To: Kevin Golder
>> Cc: ntpwg at support.ntp.org
>> Subject: Re: [ntpwg] NTPv4 MIB Revised Version 1.2
>>
>>
>> Kevin Golder schrieb:
>>
>>> Heiko,
>>>
>>> I have recently written an extension to our own private enterprise mib
>>
>>
>>> to monitor the ntpv4 daemon.  I too experienced the problem of how 
>>> to represent the floating numbers to the managers and elected 
>>> DisplayString to do so.  When I read the NTPv4 MIB you have written I
>>
>> see the 'REAL'
>>
>>> Syntax which makes me wonder how you plan on using this type.  From 
>>> what I've read about MIB's ASN.1 provides the REAL type, but when 
>>> defining MIBs the SMI doesn't allow its use.  Perhaps I have the wrong
>>
>>
>>> impression of the type REAL...
>>
>>
>> Kevin,
>>
>> thanks for your feedback. A short check of RFC1155 (SMIv1) and RFC2578
>> shows that this is true. It seems that nobody really cares about
>> floating point values when it comes to SNMP :-(
>>
>> I'd like to get data not only in string format but also as a numeric
>> value which can be used for checking upper/lower limits, therefore I
>> would suggest that I revert back to the first revision where all numeric
>> values are represented as INTEGER or Integer32 with a fixed unit applied
>> (e.g. microseconds or nanoseconds for the offset values).
>>
>> Any other ideas?
>>
>> Is there anybody out there who seconds the requirement for including
>> filter data in the MIB?
>>
>> Kind regards,
>> Heiko
>>
>>
>>
>>> Regards,
>>> Kevin
>>>
>>> -----Original Message-----
>>> From: ntpwg-bounces at support.ntp.org
>>> [mailto:ntpwg-bounces at support.ntp.org] On Behalf Of Heiko Gerstung
>>> Sent: Tuesday, January 24, 2006 3:51 AM
>>> To: David L. Mills
>>> Cc: ntpwg at support.ntp.org
>>> Subject: Re: [ntpwg] NTPv4 MIB Revised Version 1.2
>>>
>>> Dave,
>>>
>>> David L. Mills wrote:
>>>
>>>> Heiko,
>>>>
>>>> The file name extension of the first attachment is apparently not 
>>>> known to our million-dollar campus spam filter, so it was trashed. The
>>>> second attachment was apparently encrypted; the content appears
>>>
>> empty.
>>
>>>> Should you need further review, please either put it up on a web site
>>>
>>
>>>> or fake an extension such as .txt.
>>>
>>> Maybe you should tell your IT guys to return the spam filter and ask 
>>> for a full refund, since attachment filtering on the basis of 
>>> extensions seems not to be as secure as one might think...
>>>
>>> However, I understand that you can do nothing about it and I really 
>>> would like to read your comments on it, I put it on our website:
>>> http://www.meinberg.de/download/ntp/ntpv4-snmp-mib-draft.mib
>>>
>>> I could change the extension to .txt, but I guess putting it on the 
>>> web will do it for now.
>>>
>>> Regards,
>>> Heiko
>>>
>>>
>>>> Please understand the necessity of our campus anal-retentive filters.
>>>
>>
>>>> Guys like me are getting thousands of fake messages per day and 
>>>> have to find some way to trim the flood. I could ask the IT to 
>>>> allow mib extension, but that would open them to lots of requests 
>>>> for additional
>>>> holes. It probably is best to restrict all callers to txt, doc and
>>>
>>> pdf.
>>>
>>>> Yes, I know there is a macro hazard with doc, but our campus 
>>>> administration requires all staff and faculty to cope with doc
>>>
>>> paystubs.
>>>
>>>> Dave
>>>>
>>>> Heiko Gerstung wrote:
>>>>
>>>>> Happy Monday to everyone :-)
>>>>>
>>>>> Here's a revised version of the NTPv4 MIB, I only changed the data 
>>>>> types of a number of objects to be REAL (=floating point) instead of
>>>>
>>
>>>>> Integer32. Only a few bytes changed, please do not ask why it took me
>>>>> so long to do this :-}
>>>>>
>>>>> Are there any other objects missing or any other changes wanted?
>>>>>
>>>>> A side note: Please do not try to feed this into <insert your 
>>>>> favourite MIB compiler/checker here>, there are still a number of
>>>>
>>> ToDo's.
>>>
>>>>> For a starter, one would be to find a place for this MIB in the 
>>>>> MIB tree, meaning that we need to get an OID for it. I know that 
>>>>> IANA is
>>>>
>>
>>>>> responsible for enterprise OIDs, but I am not sure who is the master
>>>>
>>
>>>>> of standard MIBs.
>>>>>
>>>>> Kind regards,
>>>>> Heiko
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> -
>>>>> ---
>>>>>
>>>>> _______________________________________________
>>>>> ntpwg mailing list
>>>>> ntpwg at support.ntp.org
>>>>> https://support.ntp.org/mailman/listinfo/ntpwg
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>