[ntpwg] New Version Notification for draft-ietf-ntp-ntpv4-mib-03 and To Do list...

[Heiko Gerstung]

Chris Elliott schrieb:
> All,
> 
> As can be seen below, I have submitted the new version of the NTP MIB to 
> the draft repository. It is the version that the slides presented at the 
> working group meeting on Monday referenced.
> 
> A quick note: The slides reference an object, 
> ntpAssocStatusNotifications, in error. This object did not and does not 
> exist, thus my confusion during the presentation of the slides. There 
> are no notifications for which a count of them on a per-association 
> basis makes sense. This object was a figment of my cut/paste/modify 
> method of creating the slides.
> 
> There are two more things that need to be decided by the working group, 
> as noted in the slides:
> 
>  1. What objects should be required for NTP or SNTP entities to implement?
>  I'm going to divide this into three sub-questions:
> 
>  1a. Does the working group agree with the list of objects required of 
> SNTP entities?
>  Here's the list for your convenience:
> 
>               ntpEntSoftwareName,
>               ntpEntSoftwareVersion,
>               ntpEntSoftwareVersionVal,
>               ntpEntSoftwareVendor,
>               ntpEntSystemType,
>               ntpEntStatusEntityUptime,
>               ntpEntStatusDateTime,
>               ntpAssocName,
>               ntpAssocRefId,
>               ntpAssocAddressType,
>               ntpAssocAddress

Sounds reasonable for me.

>  1b. Do we want to require NTP entities to implement more/most/all of 
> the objects
>  in this MIB module, instead of the same limited list required of SNTP 
> entities?

I would vote for the 1a list being mandatory and the rest being optional.

>  This might include any or all of the following objects:
> 
>               ntpEntTimeResolution,
>               ntpEntTimeResolutionVal,
>               ntpEntTimePrecision,
>               ntpEntTimePrecisionVal,
>               ntpEntTimeDistance,
>               ntpEntStatusCurrentMode,
>               ntpEntStatusCurrentModeVal,
>               ntpEntStatusStratum,
>               ntpEntStatusActiveRefSourceId,
>               ntpEntStatusActiveRefSourceName,
>               ntpEntStatusActiveOffset,
>               ntpEntStatusNumberOfRefSources,
>               ntpEntStatusDispersion,
>               ntpEntStatusLeapSecond,
>               ntpEntStatusLeapSecDirection,
>               ntpEntStatusInPkts,
>               ntpEntStatusOutPkts,
>               ntpEntStatusBadVersion,
>               ntpEntStatusProtocolError,
>               ntpEntStatusNotifications,
>               ntpAssocOffset,
>               ntpAssocStratum,
>               ntpAssocStatusJitter,
>               ntpAssocStatusDelay,
>               ntpAssocStatusDispersion,
>               ntpAssocStatInPkts,
>               ntpAssocStatOutPkts,
>               ntpAssocStatProtocolError,
>               ntpEntHeartbeatInterval,
>               ntpEntNotifBits,
>               ntpEntNotifMessage
> 
>  1c. All notifications are currently optional to implement. Do we want 
> to make some or
>  all of the notifications required for SNTP or NTP entities? These 
> notifications are:
> 
>                     ntpEntNotifModeChange,
>                     ntpEntNotifStratumChange,
>                     ntpEntNotifSyspeerChanged,
>                     ntpEntNotifAddAssociation,
>                     ntpEntNotifRemoveAssociation,
>                     ntpEntNotifConfigChanged,
>                     ntpEntNotifLeapSecondAnnounced,
>                     ntpEntNotifHeartbeat

IMHO it is OK to let them be optional.

>  2. Does the working group want to add a statistics counter for each NTP 
> packet mode?
>  Heiko suggested this and I'm in favor of it. As I am not an NTP expert, 
> I am looking for
>  a consensus on this from the working group. If we do want to add this 
> statistic, do we want
>  to add it just for the entity as a whole or on a per-association basis 
> as well?

A per-association counter seems not to be useful for me, because my main 
intention was to be able to check the "load" of the entity in terms of how many 
client requests are serviced by the NTP process. The associations related 
traffic (i.e. with the upstream servers) is negligible in almost all circumstances.

> And, finally, I think there are two remaining tasks that I know about to 
> finalize the NTP MIB draft, also as noted in the slides. These include:
> 
>  1. Verifying compliance with the latest XML MIB template.
> 
>  2. Add acknowledgements for folks that have given significant input 
> into this document.
> 
> I will be working on version 4 of the draft, incorporating these last 
> two changes while I await consensus on the first two items.
> 
> Thanks in advance for your input. I believe that the next version is 
> very likely to be the last.

Great work, thanks a lot for your effort! I will review the draft in detail and 
send you my comments ASAP.

Best regards,
  Heiko

> 
> Chris.
> 
> On Dec 5, 2007, at 5:33 PM, IETF I-D Submission Tool wrote:
> 
>>
>> A new version of I-D, draft-ietf-ntp-ntpv4-mib-03.txt has been 
>> successfuly submitted by Chris Elliott and posted to the IETF repository.
>>
>> Filename:     draft-ietf-ntp-ntpv4-mib
>> Revision:     03
>> Title:         Definitions of Managed Objects for Network Time 
>> Protocol Version 4 (NTPv4)
>> Creation_date:     2007-12-05
>> WG ID:         ntp
>> Number_of_pages: 26
>>
>> Abstract:
>> The Network Time Protocol (NTP) is used in networks of all types and
>> sizes for time synchronization of servers, workstations and other
>> networked equipment.  As time synchronization is more and more a
>> mission critical service, standardized means for monitoring and
>> management of this subsystem of a networked host are required to
>> allow operators of such a service to setup a monitoring system that
>> is platform- and vendor-independant.  This Internet draft provides a
>> standardized collection of data objects for monitoring the NTP entity
>> of such a network participant and it is part of the NTP Version 4
>> standardization effort.
>>
>>
>>
>> The IETF Secretariat.
> 
> -- 
> Chris Elliott
> CCIE# 2013
> RTP, NC, USA
> +1-919-392-2146
> chelliot at cisco.com


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

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