[ntpwg] comments on draft-ietf-ntp-ntpv4-00.txt

[Heiko Gerstung]

Hi Carl,

thanks a bunch for your input, please find my comments/replies below:

Carl Kalbfleisch schrieb:
> I have reviewed the ntp mib draft and have a few comments:
> 
> 1) for ntpSrvStatusCurrentState and ntpSrvCurrentStateVal it would be
> useful to have a "noneConfigured" value to indicate that no ntp
> servers have been configured. This is a subset of not synchronized.

Wouldn't that be represented by ntpSrvStatusNumberOfRefSources = 0 ?

> 2) how is ntpAssocId different from ntpAssocIndex? At minimum some
> clarifying text in the description would be useful. if they are the
> same then remove ntpAssocId from the MIB.

My intention was to use a sequential number on the ntpAssocIndex object 
while ntpAssocId reflects the "real" association ID that, for example, 
can be shown with "ntpq -c as". Using a sequential number would IMHO 
help to iterate through the list of associations without having to find 
out which Id comes first etc.

> 3) Suggest using InetAddressType and InetAddress textual conventions
> to define address instead of the DisplayString for ntpAssocAddress.
> IE, change type for ntpAssocAddress to InetAddress and add an
> additional ntpAssocAddressType defined as InetAddressType

Is InetAddress capable of holding hostnames as well as IP addresses? 
And, are the refclock values like 127.127.0.1 valid InetAddress values? 
If yes, we could think about adding the suggested changes.

> 4) it is worth considering making the ntp mib extend the Network
> Services Monitoring MIB defined in RFC-2788. Basically the
> NtpAssociationTable becomes an extention of the assocTable in that
> MIB.
I did not review RFC-2788, yet. What would be the benefit and for whom?

> I realize 3 & 4 may look in contradiction to each other since
> RFC-2788 also uses display string to define address. However, in the
> generalized RFC-2788 case the application can also be a string name,
> not just an IP.
OK.

> 5) in the definition of ntpSrvTrappedServiceStopped description
> "stops" is misspelled as "stopps"
OK.

> 6) suggest renaming ntpSrvTraps to ntpSrvNotifications and defining
> as ntpSnmp 0, while moving the other ntpSnmp groups down 1 each.
> ntpSrvTraps is kind of misleading since the notifications could be
> inform or trap
Agreed.

> 7) create an ntpSrvNotificationObjects and move ntpSrvTrapMessage
> under that branch. It is currently under the "traps" branch but is
> not a trap
Agreed.

> 8) what are the criteria for sending the ntpSrvTrapHeartbeat?
There should be a configurable interval, I will add a comment regarding 
this. The only criteria should be that the service is running and 
replies to status queries. We could add additional (configurable) 
criterias like "I am synchronized", if anyone is interested in something 
like that.

> 9) how is the ntpSrvTraptestNotification sent? Seems like this is a
> general SNMP test mechanism. Not sure why it is here/needed.
It should be possible within the application/service to initiate such a 
test trap, to check that the configured trap receiver(s) and community 
works as expected.

> 10) why is ntpSrvSyetmType needed? Suggest removing it. Isn't this
> information already provided in sysDescr described in RFC-1213 as "A
> textual description of the entity.  This value should include the
> full name and version identification of the system's hardware type,
> software operating-system, and networking software."
The content of this file is taken from the NTP system variable as shown 
in a "ntpq -c rv" output. But I have no objections against removing it, 
if no one else wants it.

Best regards,
Heiko



> Carl
> 
> _______________________________________________ ntpwg mailing list 
> ntpwg at support.ntp.org 
> https://support.ntp.org/mailman/listinfo/ntpwg


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

*MEINBERG Funkuhren GmbH & Co. KG*
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