comments on draft-ietf-ntp-ntpv4-00.txt

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.

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.

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

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

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

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

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

8) what are the criteria for sending the
ntpSrvTrapHeartbeat?

9) how is the ntpSrvTraptestNotification sent? Seems like
this is a general SNMP test mechanism. Not sure why it is
here/needed.

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

Carl

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

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 
> ntpwglists.ntp.isc.org 
> http
s://lists.ntp.isc.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.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

Hi Heiko,

On Oct 16, 2006, at 3:13, Heiko Gerstung wrote:
>
>> 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.
>
>

The InetAddressTC is defined in RFC 4001.  The
InetAddressType supports 
entries that are DNS names, IPv4 addresses, IPv6 addresses,
scoped IPv4 
addresses, scoped IPv6 addresses, and unknown.  It should
work well in 
this context.

Regards,
Brian

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

Hi Brian,

Brian Haberman schrieb:
> Hi Heiko,
> 
> On Oct 16, 2006, at 3:13, Heiko Gerstung wrote:
>>
>>> 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.
>>
>>
> 
> The InetAddressTC is defined in RFC 4001.  The
InetAddressType supports 
> entries that are DNS names, IPv4 addresses, IPv6
addresses, scoped IPv4 
> addresses, scoped IPv6 addresses, and unknown.  It
should work well in 
> this context.

OK, thanks for your explanation and help. I think I will use
that TC, 
sounds like this really makes sense for our application.

Best regards,
Heiko



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

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