NTPv4 MIB Revised Version 1.2

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?

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.

Regards,
Kevin 

-----Original Message-----
From: Heiko Gerstung [mailto:heiko.gerstungmeinberg.de] 
Sent: Tuesday, January 24, 2006 10:12 AM
To: Kevin Golder
Cc: ntpwglists.ntp.isc.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-bounceslists.ntp.isc.org
> [mailto:ntpwg-bounceslists.ntp.isc.org] On
Behalf Of Heiko Gerstung
> Sent: Tuesday, January 24, 2006 3:51 AM
> To: David L. Mills
> Cc: ntpwglists.ntp.isc.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-d
raft.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
>>> ntpwglists.ntp.isc.org
>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwglists.ntp.isc.org
>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
> 
>
------------------------------------------------------------
----------
> --
> 
> Meinberg radio clocks: 25 years of accurate time
worldwide
> 
> _______________________________________________
> ntpwg mailing list
> ntpwglists.ntp.isc.org
> http
s://lists.ntp.isc.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.gerstungmeinberg.de <mailto:heiko.gerstungmeinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/&g
t;

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

Meinberg radio clocks: 25 years of accurate time worldwide

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

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.gerstungmeinberg.de] 
> Sent: Tuesday, January 24, 2006 10:12 AM
> To: Kevin Golder
> Cc: ntpwglists.ntp.isc.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-bounceslists.ntp.isc.org
>> [mailto:ntpwg-bounceslists.ntp.isc.org] On
Behalf Of Heiko Gerstung
>> Sent: Tuesday, January 24, 2006 3:51 AM
>> To: David L. Mills
>> Cc: ntpwglists.ntp.isc.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-d
raft.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
>>>> ntpwglists.ntp.isc.org
>>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwglists.ntp.isc.org
>>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
>> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
>>
>>
------------------------------------------------------------
----------
>> --
>>
>> Meinberg radio clocks: 25 years of accurate time
worldwide
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwglists.ntp.isc.org
>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
> 
>
------------------------------------------------------------
------------
> 
> Meinberg radio clocks: 25 years of accurate time
worldwide
> 
> 


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

*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.gerstungmeinberg.de <mailto:heiko.gerstungmeinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/&g
t;

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

Meinberg radio clocks: 25 years of accurate time worldwide

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

 	Hello Kevin ,

On Tue, 24 Jan 2006, Kevin Golder wrote:
> 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?
>
> 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.
 	What is wrong with Integer64 ?  iirc ,  the I64 does exist
as a
 	valid snmp variable type .  Please correct if wrong .
 		Hth ,  JimL

> -----Original Message-----
> From: Heiko Gerstung [mailto:heiko.gerstungmeinberg.de]
> Sent: Tuesday, January 24, 2006 10:12 AM
> To: Kevin Golder
> Cc: ntpwglists.ntp.isc.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-bounceslists.ntp.isc.org
>> [mailto:ntpwg-bounceslists.ntp.isc.org] On
Behalf Of Heiko Gerstung
>> Sent: Tuesday, January 24, 2006 3:51 AM
>> To: David L. Mills
>> Cc: ntpwglists.ntp.isc.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-d
raft.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
>>>> ntpwglists.ntp.isc.org
>>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwglists.ntp.isc.org
>>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
>> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
>>
>>
------------------------------------------------------------
----------
>> --
>>
>> Meinberg radio clocks: 25 years of accurate time
worldwide
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwglists.ntp.isc.org
>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
>
>
------------------------------------------------------------
------------
>
> Meinberg radio clocks: 25 years of accurate time
worldwide
>
> _______________________________________________
> ntpwg mailing list
> ntpwglists.ntp.isc.org
> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>

-- 
+-----------------------------------------------------------
-------+
| James   W.   Laferriere | System    Techniques | Give me
VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me
Linux  |
| babydrbaby-dragons.com | Billings , MT. 59105 |   only  on 
AXP |
|  http://www.asteriskhelpdesk.com/cgi-bin/astlance/r.
cgi?babydr   |
+-----------------------------------------------------------
-------+
_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

Mr. James W. Laferriere schrieb:
>     Hello Kevin ,
> 
> On Tue, 24 Jan 2006, Kevin Golder wrote:
>> 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?
>>
>> 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.
>     What is wrong with Integer64 ?  iirc ,  the I64
does exist as a
>     valid snmp variable type .  Please correct if wrong
.
>         Hth ,  JimL

Hi, James:

As far as I can see, RFC2578 (SMIv2) does not mention
Integer64 ...

Regards,
Heiko

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

*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.gerstungmeinberg.de <mailto:heiko.gerstungmeinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/&g
t;

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

Meinberg radio clocks: 25 years of accurate time worldwide

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

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.gerstungmeinberg.de] Sent: 
>> Tuesday, January 24, 2006 10:12 AM
>> To: Kevin Golder
>> Cc: ntpwglists.ntp.isc.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-bounceslists.ntp.isc.org
>>> [mailto:ntpwg-bounceslists.ntp.isc.org] On
Behalf Of Heiko Gerstung
>>> Sent: Tuesday, January 24, 2006 3:51 AM
>>> To: David L. Mills
>>> Cc: ntpwglists.ntp.isc.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-d
raft.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
>>>>> ntpwglists.ntp.isc.org
>>>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>>>
>>>>
_______________________________________________
>>>> ntpwg mailing list
>>>> ntpwglists.ntp.isc.org
>>>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
>>> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
>>>
>>>
------------------------------------------------------------
----------
>>> -- 
>>>
>>> Meinberg radio clocks: 25 years of accurate
time worldwide
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwglists.ntp.isc.org
>>> http
s://lists.ntp.isc.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.gerstungmeinberg.de
<mailto:heiko.gerstungmeinberg.de>
>> Internet: www.meinberg.de <http://www.meinberg.de/&g
t;
>>
>>
------------------------------------------------------------
------------
>>
>> Meinberg radio clocks: 25 years of accurate time
worldwide
>>
>>
>
>

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

At 4:52 PM +0100 2006-01-24, Heiko Gerstung wrote:

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

	I'm confused.  Why can't we use ASCII strings as the
transport 
mechanism, and then have the SNMP client do whatever numeric

conversion that it may want to do to the data, and then take
whatever 
action it feels is appropriate based on the result?

	This way, your client doesn't have to worry what the
internal 
numeric representation is on the server, and you can have
multiple 
different clients with differing numeric capabilities, and
it won't 
matter.

-- 
Brad Knowles, <bradstop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase
a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the
Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.

_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

David L. Mills wrote:
> 
> Is it the expectation of this group that the MIB apply
only to NTPv4?
> Does this isolate NTPv3?
> 
> Dave
> 
I don't see how you can do anything different since not only
are we not
maintaining NTP v3 but how would you get anyone to upgrade
an NTP v3
ntpd to support MIBstuff? If they are serious about
monitoring they
would be serious about upgrading to NTP v4. I can't see how
it could be
any other way. The only other thing would be to create a
separate
application to run on the same server to make mode-6 queries
of the V3
daemon and act as the MIB service. A kind-of wart-on
service.

Danny
_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

Danny,

I wasn't advising whether or not to consider NTPv3, just
casting for 
opinions. I do observe disingeniously that, while not a
perfect match, a 
proxy agent could serve NTPv3 as well as NTPv4.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> Is it the expectation of this group that the MIB
apply only to NTPv4?
>> Does this isolate NTPv3?
>>
>> Dave
>>
> I don't see how you can do anything different since not
only are we not
> maintaining NTP v3 but how would you get anyone to
upgrade an NTP v3
> ntpd to support MIBstuff? If they are serious about
monitoring they
> would be serious about upgrading to NTP v4. I can't see
how it could be
> any other way. The only other thing would be to create
a separate
> application to run on the same server to make mode-6
queries of the V3
> daemon and act as the MIB service. A kind-of wart-on
service.
>
> Danny


_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg