From hhenriksen@stofanet.dk  Wed Aug 18 13:07:49 2010
Return-Path: <hhenriksen@stofanet.dk>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5AF3A6A6A for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Wed, 18 Aug 2010 13:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.64
X-Spam-Level: ***
X-Spam-Status: No, score=3.64 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, US_DOLLARS_3=0.63]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xXejRlUi+ic for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Wed, 18 Aug 2010 13:07:49 -0700 (PDT)
Received: from mx03.stofanet.dk (mx03.stofanet.dk [212.10.10.13]) by core3.amsl.com (Postfix) with ESMTP id DBE0A3A6A67 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Wed, 18 Aug 2010 13:07:45 -0700 (PDT)
Received: from web01.stofanet.dk ([212.10.10.15] helo=webmail.stofa.dk) by mx03.stofanet.dk (envelope-from <hhenriksen@stofanet.dk>) with esmtp id 1Olou3-0000xX-0i; Wed, 18 Aug 2010 22:06:27 +0200
Date: Wed, 18 Aug 2010 22:06:26 +0200
To: undisclosed-recipients:;
From: "Mr Alex Flockhart." <hhenriksen@stofanet.dk>
Reply-to: "Mr Alex Flockhart." <aaflockharrt@yahoo.com.hk>
Subject: Hello
Message-ID: <012ea53ae00c47a492ea766c6a148e36@webmail.stofa.dk>
X-Priority: 3
X-Mailer: Telia Stofa WebMail [1.73]
X-Authinfo: 1119934m002
X-Originating-IP: [188.65.178.161]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_012ea53ae00c47a492ea766c6a148e36"

--b1_012ea53ae00c47a492ea766c6a148e36
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hello

I have a Business Proposal of ($24,500,000.00 usd) for you to handle with
me from my bank, can You be of Assistance as a Partner?
I shall give you Details when You reply.

This is my private email: aaflockharrt@yahoo.com.hk
Regards,
Mr Alex Flockhart.


--b1_012ea53ae00c47a492ea766c6a148e36
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<font face=3D"verdana, arial, helvetic" size=3D2><P><FONT face=3D"verdana, =
arial, helvetic" size=3D2>Hello</FONT></P><BR />
<P><FONT face=3D"verdana, arial, helvetic" size=3D2>I have a Business =
Proposal of ($24,500,000.00 usd) for you to handle with<BR>me from my =
bank, can You be of Assistance as a Partner?<BR>I shall give you Details =
when You reply.</FONT></P><BR />
<P><FONT face=3D"verdana, arial, helvetic" size=3D2>This is my private =
email: <A href=3D"mailto:aaflockharrt@yahoo.com.hk">aaflockharrt@yahoo.com=
.hk</A><BR>Regards,<BR>Mr Alex Flockhart.</FONT></P></FONT>



--b1_012ea53ae00c47a492ea766c6a148e36--



From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Tue Aug 24 08:22:45 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3443A6A4C for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Tue, 24 Aug 2010 08:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.266
X-Spam-Level: 
X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVWh7IgGvwAg for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Tue, 24 Aug 2010 08:22:41 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 349493A6B83 for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 24 Aug 2010 08:22:37 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4B03486D789 for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 24 Aug 2010 15:23:07 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id 373DF86D41E for <ntpwg@lists.ntp.org>; Tue, 24 Aug 2010 15:17:47 +0000 (UTC)
Received: from antivir1.rad.co.il ([62.0.23.193]) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <yaakov_s@rad.com>) id 1OnvFp-0003kN-5e for ntpwg@lists.ntp.org; Tue, 24 Aug 2010 15:17:47 +0000
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Aug 2010 18:17:28 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 24 Aug 2010 18:16:53 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: NTP Working Group <ntpwg@lists.ntp.org>
Date: Tue, 24 Aug 2010 18:16:50 +0300
Thread-Topic: question regarding RFC 5907
Thread-Index: Acss8iAeuCRFejZnTpO0MJZEP4TelAWqctAw
Message-ID: <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>
References: <4C4DD405.6040207@pobox.com>
In-Reply-To: <4C4DD405.6040207@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {F420CA8B-6C25-49F3-8E94-A6CCBA19B2FC}
x-cr-hashedpuzzle: AXTu CdcA CnRp Cx4H DDoy DjnY EqUH Ff8P GX85 GX88 Gvm5 IoQE JGW1 JvF1 Km1e Kyrs; 1; bgB0AHAAdwBnAEAAbABpAHMAdABzAC4AbgB0AHAALgBvAHIAZwA=; Sosha1_v1; 7; {F420CA8B-6C25-49F3-8E94-A6CCBA19B2FC}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Tue, 24 Aug 2010 15:16:50 GMT; cQB1AGUAcwB0AGkAbwBuACAAcgBlAGcAYQByAGQAaQBuAGcAIABSAEYAQwAgADUAOQAwADcA
acceptlanguage: en-US
MIME-Version: 1.0
X-SA-Exim-Connect-IP: 62.0.23.193
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: yaakov_s@rad.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
Subject: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

NTP experts, 

The NTPv4 MIB RFC starts with the following sentence
   The NTPv4 MIB module is designed to allow Simple Network Management
   Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
   entities.

While I see the monitoring elements, I do not see the management (i.e. configuration) ones.

In particular, RFC 5905's global parameters are all in #defines in the Appendix,
rather than being configurable via the MIB.

For example, I would like to be able to change MINPOLL or MINDISP
from a management entity instead of having to recompile.
I am obviously not the only one who sees an advantage to changing these 
as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.

ooops!!


Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
Perhaps it was considered better to use netconf ;) 


Y(J)S


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Tue Aug 24 19:23:28 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D853A695B for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Tue, 24 Aug 2010 19:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLnFkWnIu89d for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Tue, 24 Aug 2010 19:23:20 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 94F533A67FB for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 24 Aug 2010 19:23:19 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4C54886D76D for <ntp-archives-ahFae6za@lists.ietf.org>; Wed, 25 Aug 2010 02:23:50 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id F10C986D41E for <ntpwg@lists.ntp.org>; Wed, 25 Aug 2010 02:22:31 +0000 (UTC)
Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <mills@udel.edu>) id 1Oo5d6-000MWO-Ox for ntpwg@lists.ntp.org; Wed, 25 Aug 2010 02:22:31 +0000
Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id AA640697; Tue, 24 Aug 2010 22:22:19 -0400 (EDT)
Message-ID: <4C747E59.5050909@udel.edu>
Date: Wed, 25 Aug 2010 02:22:17 +0000
From: "David L. Mills" <mills@udel.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>
References: <4C4DD405.6040207@pobox.com> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>
In-Reply-To: <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>
X-SA-Exim-Connect-IP: 128.4.40.12
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: mills@udel.edu
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

Yaakov,

Engineering parameters like MINPOLL and others establish ranges over 
which the algorithms are intended to work reliably. The hardcoded 
defines cannot be changed unless all engineering considerations have 
been explored. In the case (only) of MINPOLL, and as the result of the 
rate management improvements, MINPOLL has been reduced to 8 s from the 
former 16 s. Any attempt to lower this number will result in clock 
feedback loop instability. The preferred way to control the poll 
interval is using ntpq and the configuration commands.

There are zillions of ways to monitor and/or modify ntpd behavior in 
legitimate ways using ntpq and ntpdc, most of which are awkward or 
impossible with presents SNMP. Floating around here somewhere is a SNMP 
agent designed to interface with the NTP monitoring and control protocol 
first implemented in 1981. There are at present no plans to support SNMP 
directly in ntpd.

Dave

Yaakov Stein wrote:

>NTP experts, 
>
>The NTPv4 MIB RFC starts with the following sentence
>   The NTPv4 MIB module is designed to allow Simple Network Management
>   Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
>   entities.
>
>While I see the monitoring elements, I do not see the management (i.e. configuration) ones.
>
>In particular, RFC 5905's global parameters are all in #defines in the Appendix,
>rather than being configurable via the MIB.
>
>For example, I would like to be able to change MINPOLL or MINDISP
>from a management entity instead of having to recompile.
>I am obviously not the only one who sees an advantage to changing these 
>as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
>while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
>
>ooops!!
>
>
>Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
>Perhaps it was considered better to use netconf ;) 
>
>
>Y(J)S
>
>
>_______________________________________________
>ntpwg mailing list
>ntpwg@lists.ntp.org
>http://lists.ntp.org/listinfo/ntpwg
>  
>

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Fri Aug 27 19:54:14 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8203A677D for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Fri, 27 Aug 2010 19:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOVD4pH2QK-a for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Fri, 27 Aug 2010 19:54:12 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 7A9323A677C for <ntp-archives-ahFae6za@lists.ietf.org>; Fri, 27 Aug 2010 19:54:12 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C3DEE86D75F for <ntp-archives-ahFae6za@lists.ietf.org>; Sat, 28 Aug 2010 02:54:40 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id 471C486D75C for <ntpwg@lists.ntp.org>; Wed, 25 Aug 2010 06:33:23 +0000 (UTC)
Received: from rrzmta2.rz.uni-regensburg.de ([194.94.155.52]) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <Ulrich.Windl@rz.uni-regensburg.de>) id 1Oo9Xs-00054G-Dy for ntpwg@lists.ntp.org; Wed, 25 Aug 2010 06:33:23 +0000
Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5BA381249 for <ntpwg@lists.ntp.org>; Wed, 25 Aug 2010 08:33:05 +0200 (CEST)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.rz.uni-regensburg.de [132.199.5.51]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 381F41157 for <ntpwg@lists.ntp.org>; Wed, 25 Aug 2010 08:33:05 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 25 Aug 2010 08:33:05 +0200
Message-Id: <4C74D53F020000A10000EB15@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 8.0.2 
Date: Wed, 25 Aug 2010 08:33:03 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <ntpwg@lists.ntp.org>
Mime-Version: 1.0
Content-Disposition: inline
X-SA-Exim-Connect-IP: 194.94.155.52
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
X-Mailman-Approved-At: Sat, 28 Aug 2010 02:54:25 +0000
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

Note: The original reply had a typo in the CC:, so the list did not get it)
>>> Ulrich Windl schrieb am 25.08.2010 um 08:24 in Nachricht
<4C74D4E9.ED3C.00A1.0@rz.uni-regensburg.de>:
> >>> Yaakov Stein <yaakov_s@rad.com> schrieb am 24.08.2010 um 17:16 in Nachricht
> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>:
> > NTP experts, 
> > 
> > The NTPv4 MIB RFC starts with the following sentence
> >    The NTPv4 MIB module is designed to allow Simple Network Management
> >    Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
> >    entities.
> > 
> > While I see the monitoring elements, I do not see the management (i.e. 
> > configuration) ones.
> > 
> > In particular, RFC 5905's global parameters are all in #defines in the 
> > Appendix,
> > rather than being configurable via the MIB.
> > 
> > For example, I would like to be able to change MINPOLL or MINDISP
> > from a management entity instead of having to recompile.
> > I am obviously not the only one who sees an advantage to changing these 
> > as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
> > while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
> > 
> > ooops!!
> > 
> > 
> > Can someone explain the design considerations that led to leaving these out 
> > of the 5907 MIB ?
> 
> Hi!
> 
> From what I've heard, the MIB is just a paper tiger, meaning: It's not 
> implemented yet. I had some private discussion that an implementation should 
> preceed an RFC. From another private discussion, I doubt that the SNMP 
> interface if based on the current mode 6 responses of ntpd (the way it's 
> intended to be implemented) will ever be reliable.
> You cannot build a great framework on top of a poor base. IMHO the current 
> (actually the very old) format of mode 6 responses are designed for humans to 
> read and understand, but are quite bad for computer programs to parse (I have 
> written several parsers for the output, so I know what I'm talking about).
> Everybody is invited to convince me of the opposite.
> 
> Regards,
> Ulrich
> 
> 


 

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Sat Aug 28 19:19:17 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1459B3A6894 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Sat, 28 Aug 2010 19:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIUjv6DMfCUs for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Sat, 28 Aug 2010 19:19:15 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 319933A6922 for <ntp-archives-ahFae6za@lists.ietf.org>; Sat, 28 Aug 2010 19:19:15 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4198B86DA57 for <ntp-archives-ahFae6za@lists.ietf.org>; Sun, 29 Aug 2010 02:19:43 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7FDA786D34D for <ntpwg@lists.ntp.org>; Sun, 29 Aug 2010 02:19:29 +0000 (UTC)
Received: from cust-63-209-227-45.bos-dynamic.gis.net ([63.209.227.45] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <mayer@ntp.org>) id 1OpXUK-0005qR-2w; Sun, 29 Aug 2010 02:19:26 +0000
Message-ID: <4C79C3A5.9000808@ntp.org>
Date: Sat, 28 Aug 2010 22:19:17 -0400
From: Danny Mayer <mayer@ntp.org>
Organization: NTP
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>
References: <4C4DD405.6040207@pobox.com> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>
In-Reply-To: <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>
X-Enigmail-Version: 1.1.1
X-SA-Exim-Connect-IP: 63.209.227.45
X-SA-Exim-Rcpt-To: yaakov_s@rad.com, ntpwg@lists.ntp.org, heiko.gerstung@meinberg.de
X-SA-Exim-Mail-From: mayer@ntp.org
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mayer@ntp.org
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

On 8/24/2010 11:16 AM, Yaakov Stein wrote:
> NTP experts, 
> 
> The NTPv4 MIB RFC starts with the following sentence
>    The NTPv4 MIB module is designed to allow Simple Network Management
>    Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
>    entities.
> 
> While I see the monitoring elements, I do not see the management (i.e. configuration) ones.
> 
> In particular, RFC 5905's global parameters are all in #defines in the Appendix,
> rather than being configurable via the MIB.
> 

You need to ask the author of the MIB RFC about that. I'm copying him on
this message.

> For example, I would like to be able to change MINPOLL or MINDISP
> from a management entity instead of having to recompile.
> I am obviously not the only one who sees an advantage to changing these 
> as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
> while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
> 
> ooops!!
> 

In the reference implementation ntpd uses them in lieu of values entered
on the server configuration lines. In other words if you don't specify
the minpoll and maxpoll values it will use the defined macro values.
That's a pretty standard way of specifying it.

I don't think that the reference implementation of a MIB client includes
a management option. ntpd always uses ntpq and ntpdc to manage the ntp
server. I know of no plans to change that. It doesn't mean that another
implementation might not provide it, merely that the reference
implementation doesn't.

Danny

> 
> Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
> Perhaps it was considered better to use netconf ;) 
> 
> 
> Y(J)S

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Sun Aug 29 23:26:06 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E803A67A4 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Sun, 29 Aug 2010 23:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lOrDr2SrTQr for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Sun, 29 Aug 2010 23:26:03 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 5B3973A67B1 for <ntp-archives-ahFae6za@lists.ietf.org>; Sun, 29 Aug 2010 23:26:03 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C554486D763 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 06:26:30 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id 393F486D34D for <ntpwg@lists.ntp.org>; Mon, 30 Aug 2010 06:26:09 +0000 (UTC)
Received: from alster074.server4you.de ([62.75.216.94] helo=server2.meinberg.de) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <heiko.gerstung@meinberg.de>) id 1Opxoc-000MrL-Oe for ntpwg@lists.ntp.org; Mon, 30 Aug 2010 06:26:09 +0000
Received: from localhost (localhost [127.0.0.1]) by server2.meinberg.de (Postfix) with ESMTP id AFCCA1EC4641; Mon, 30 Aug 2010 08:25:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at meinberg.de
Received: from server2.meinberg.de ([127.0.0.1]) by localhost (server2.meinberg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrz2ay+iOB7E; Mon, 30 Aug 2010 08:25:42 +0200 (CEST)
Received: from gateway.py.meinberg.de (unknown [217.5.178.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by server2.meinberg.de (Postfix) with ESMTP id 65C111EC4572; Mon, 30 Aug 2010 08:25:42 +0200 (CEST)
Received: from [172.16.100.113] (pc-heiko.py.meinberg.de [172.16.100.113]) by gateway.py.meinberg.de (Postfix) with ESMTP id 12190250B55; Mon, 30 Aug 2010 08:25:42 +0200 (CEST)
Message-ID: <4C7B4EE6.2090707@meinberg.de>
Date: Mon, 30 Aug 2010 08:25:42 +0200
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6
MIME-Version: 1.0
To: mayer@ntp.org
References: <4C4DD405.6040207@pobox.com> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il> <4C79C3A5.9000808@ntp.org>
In-Reply-To: <4C79C3A5.9000808@ntp.org>
X-SA-Exim-Connect-IP: 62.75.216.94
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: heiko.gerstung@meinberg.de
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

Am 29.08.2010 04:19, schrieb Danny Mayer:
> On 8/24/2010 11:16 AM, Yaakov Stein wrote:
>   =

>> NTP experts, =

>>
>> The NTPv4 MIB RFC starts with the following sentence
>>    The NTPv4 MIB module is designed to allow Simple Network Management
>>    Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
>>    entities.
>>
>> While I see the monitoring elements, I do not see the management (i.e. c=
onfiguration) ones.
>>
>> In particular, RFC 5905's global parameters are all in #defines in the A=
ppendix,
>> rather than being configurable via the MIB.
>>
>>     =

> You need to ask the author of the MIB RFC about that. I'm copying him on
> this message.
>   =

Yes, thanks for that, Danny. I would say that mentioning management is
wrong at this point, although I would like to see this being added in a
future version of the MIB.

>> For example, I would like to be able to change MINPOLL or MINDISP
>> from a management entity instead of having to recompile.
>> I am obviously not the only one who sees an advantage to changing these =

>> as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
>> while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
>>
>> ooops!!
>>
>>     =

> In the reference implementation ntpd uses them in lieu of values entered
> on the server configuration lines. In other words if you don't specify
> the minpoll and maxpoll values it will use the defined macro values.
> That's a pretty standard way of specifying it.
>   =

Yes, and thats perfectly fine for default values. After all, you need
default values being defined at compile time. But it sounds like Yaakov
wants to configure the values at run time.
> I don't think that the reference implementation of a MIB client includes
> a management option. ntpd always uses ntpq and ntpdc to manage the ntp
> server. I know of no plans to change that. It doesn't mean that another
> implementation might not provide it, merely that the reference
> implementation doesn't.
>   =

A lot of my customers and myself would like to see that ntpd allows to
use broadly accepted and implemented standard protocols like SNMP for
monitoring and management instead of using implementation specific
protocols. It is even worse with ntpdc which is not even compatible
between different versions of NTP and therefore is simply not usable for
central configuration management of a diverse population of ntpd's.

Someone else brought up the ntpq argument during the discussions about
the MIB and although I have no problems with ntpq and ntpdc when it
comes to manually look at ntpd's from time to time, they are pretty
clumsy when it comes to automated central monitoring and management.
Therefore I would like to see a future version of the MIB to include
management objects as well and I would want to see this being
implemented in the SNMP daemon of the reference implementation. But it
simply did not make it into RFC 5907, just because I did not have the
ressources to work on that and nobody else brought this up before(!) the
RFC has been published.

Best Regards,
  Heiko


> Danny
>
>   =

>> Can someone explain the design considerations that led to leaving these =
out of the 5907 MIB ?
>> Perhaps it was considered better to use netconf ;) =

>>
>>
>> Y(J)S
>>     =

>   =



-- =


Heiko Gerstung

*MEINBERG Funkuhren* GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: +49 (0)5281 9309-25
Fax: +49 (0)5281 9309-30
Amtsgericht Hannover 17HRA 100322
Gesch=E4ftsf=FChrer/Managing Directors: G=FCnter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Email: heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>
Web: www.meinberg.de <http://www.meinberg.de>

------------------------------------------------------------------------
*MEINBERG - Accurate Time Worldwide*


_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Mon Aug 30 03:34:27 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40D13A6781 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 03:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.278
X-Spam-Level: 
X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzkA-+IusUC8 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 03:34:23 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id CBFC23A67A3 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 03:34:22 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id ED0F086D78D for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 10:34:51 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id C03A486D34D for <ntpwg@lists.ntp.org>; Mon, 30 Aug 2010 10:34:38 +0000 (UTC)
Received: from mx1-q.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <yaakov_s@rad.com>) id 1Oq1h5-0003WK-DO for ntpwg@lists.ntp.org; Mon, 30 Aug 2010 10:34:38 +0000
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 30 Aug 2010 13:34:17 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 30 Aug 2010 13:33:51 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: "David L. Mills" <mills@udel.edu>
Date: Mon, 30 Aug 2010 13:33:49 +0300
Thread-Topic: [ntpwg] question regarding RFC 5907
Thread-Index: ActD/ETqVWjJF6QMRZ+H/FXyKBJRMQEL5HiQ
Message-ID: <48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il>
References: <4C4DD405.6040207@pobox.com> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il> <4C747E59.5050909@udel.edu>
In-Reply-To: <4C747E59.5050909@udel.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-SA-Exim-Connect-IP: 80.74.100.136
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: yaakov_s@rad.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

Dave, 

Thanks for the response.

Yes, I realize that changing values of parameters requires care
and, perhaps more importantly, understanding.

However, I can change a broad range of variables in my present
frequency distribution implementations (based on TDM PWs or 1588),
including relatively sensitive ones such as packet rates,
filter bandwidths, thresholds for constant delay change detection, 
various Kalman filter parameters, etc.

This feature is extremely useful as the same algorithm may be called
upon to run in many different scenarios, e.g., a large number of 
network elements that are typically not very highly loaded (i.e. Gaussian PDV),
a small number of more heavily loaded ones (i.e., with delta function at minimum delay),
a single switch with other high-rate synchronous flows, etc.

The standard way such configuration is handled is via a management station
over the network with SNMP. Yes, I realize that NTP was born in another
type of environment, where other modes of configuration 
(or even simply recompilation) are prevalent; 
but it is being used in service provider networks, and this kind of management is needed.

I would appreciate hearing what modifications of NTP behavior
are easy using ntpq but awkward or impossible using SNMP.

Y(J)S



-----Original Message-----
From: David L. Mills [mailto:mills@udel.edu] 
Sent: Wednesday, August 25, 2010 05:22
To: Yaakov Stein
Cc: NTP Working Group
Subject: Re: [ntpwg] question regarding RFC 5907

Yaakov,

Engineering parameters like MINPOLL and others establish ranges over 
which the algorithms are intended to work reliably. The hardcoded 
defines cannot be changed unless all engineering considerations have 
been explored. In the case (only) of MINPOLL, and as the result of the 
rate management improvements, MINPOLL has been reduced to 8 s from the 
former 16 s. Any attempt to lower this number will result in clock 
feedback loop instability. The preferred way to control the poll 
interval is using ntpq and the configuration commands.

There are zillions of ways to monitor and/or modify ntpd behavior in 
legitimate ways using ntpq and ntpdc, most of which are awkward or 
impossible with presents SNMP. Floating around here somewhere is a SNMP 
agent designed to interface with the NTP monitoring and control protocol 
first implemented in 1981. There are at present no plans to support SNMP 
directly in ntpd.

Dave

Yaakov Stein wrote:

>NTP experts, 
>
>The NTPv4 MIB RFC starts with the following sentence
>   The NTPv4 MIB module is designed to allow Simple Network Management
>   Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
>   entities.
>
>While I see the monitoring elements, I do not see the management (i.e. configuration) ones.
>
>In particular, RFC 5905's global parameters are all in #defines in the Appendix,
>rather than being configurable via the MIB.
>
>For example, I would like to be able to change MINPOLL or MINDISP
>from a management entity instead of having to recompile.
>I am obviously not the only one who sees an advantage to changing these 
>as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
>while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
>
>ooops!!
>
>
>Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
>Perhaps it was considered better to use netconf ;) 
>
>
>Y(J)S
>
>
>_______________________________________________
>ntpwg mailing list
>ntpwg@lists.ntp.org
>http://lists.ntp.org/listinfo/ntpwg
>  
>

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Mon Aug 30 05:08:00 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDB53A6A18 for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 05:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXX9d4tpo0yD for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 05:07:51 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 7B3BC3A69B7 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 05:05:35 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 29B9F86D764 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 12:06:04 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id CBAF586D34D for <ntpwg@lists.ntp.org>; Mon, 30 Aug 2010 12:05:55 +0000 (UTC)
Received: from [198.22.153.9] (helo=[10.60.111.40]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <mayer@ntp.org>) id 1Oq37N-000GLH-Ro; Mon, 30 Aug 2010 12:05:52 +0000
Message-ID: <4C7B9E93.3020404@ntp.org>
Date: Mon, 30 Aug 2010 08:05:39 -0400
From: Danny Mayer <mayer@ntp.org>
Organization: NTP
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>
References: <4C4DD405.6040207@pobox.com>	<48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il>	<4C747E59.5050909@udel.edu> <48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il>
In-Reply-To: <48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il>
X-Enigmail-Version: 1.1.1
X-SA-Exim-Connect-IP: 198.22.153.9
X-SA-Exim-Rcpt-To: yaakov_s@rad.com, mills@udel.edu, ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: mayer@ntp.org
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mayer@ntp.org
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

Right now it's impossible using SNMP since the interface does not exist
in the reference implementation. To add that to ntpd would require
building a whole new interface capability which would have to be
architectured, designed and implemented. A second possibility is to have
SNMP interface with ntpq to perform the actual changes which have the
same if less onerous problems as ntpd. Heiko has build an SNMP interface
to ntpq for reading the data but not for updating ntpd. Another option
is to build an SNMP application which uses the NTP mode 6 packets to do
it directly. That could be done but has the same hurdles as above.

Danny

On 8/30/2010 6:33 AM, Yaakov Stein wrote:
> Dave, 
> 
> Thanks for the response.
> 
> Yes, I realize that changing values of parameters requires care
> and, perhaps more importantly, understanding.
> 
> However, I can change a broad range of variables in my present
> frequency distribution implementations (based on TDM PWs or 1588),
> including relatively sensitive ones such as packet rates,
> filter bandwidths, thresholds for constant delay change detection, 
> various Kalman filter parameters, etc.
> 
> This feature is extremely useful as the same algorithm may be called
> upon to run in many different scenarios, e.g., a large number of 
> network elements that are typically not very highly loaded (i.e. Gaussian PDV),
> a small number of more heavily loaded ones (i.e., with delta function at minimum delay),
> a single switch with other high-rate synchronous flows, etc.
> 
> The standard way such configuration is handled is via a management station
> over the network with SNMP. Yes, I realize that NTP was born in another
> type of environment, where other modes of configuration 
> (or even simply recompilation) are prevalent; 
> but it is being used in service provider networks, and this kind of management is needed.
> 
> I would appreciate hearing what modifications of NTP behavior
> are easy using ntpq but awkward or impossible using SNMP.
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org  Mon Aug 30 11:54:33 2010
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A083A684D for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 11:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMwW6lQ0wxUe for <ietfarch-ntp-archives-ahFae6za@core3.amsl.com>; Mon, 30 Aug 2010 11:54:30 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by core3.amsl.com (Postfix) with ESMTP id 187513A67FE for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 11:54:29 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 432A186D77B for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 30 Aug 2010 18:54:59 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail2.ntp.org (mail2.ntp.org [IPv6:2001:4f8:fff7:1::6]) by lists.ntp.org (Postfix) with ESMTP id E2EF386D34D for <ntpwg@lists.ntp.org>; Mon, 30 Aug 2010 18:54:41 +0000 (UTC)
Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail2.ntp.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <mills@udel.edu>) id 1Oq9V0-000HyU-6B for ntpwg@lists.ntp.org; Mon, 30 Aug 2010 18:54:41 +0000
Received: from [192.168.1.3] (pool-74-109-9-238.phlapa.fios.verizon.net [74.109.9.238]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 4164EDC2 for <ntpwg@lists.ntp.org>; Mon, 30 Aug 2010 14:54:29 -0400 (EDT)
Message-ID: <4C7BFE60.8030608@udel.edu>
Date: Mon, 30 Aug 2010 18:54:24 +0000
From: "David L. Mills" <mills@udel.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: NTP Working Group <ntpwg@lists.ntp.org>
References: <4C4DD405.6040207@pobox.com> <48E7911F78327A449A9FB95637667286A2BA6D15@exrad4.ad.rad.co.il> <4C747E59.5050909@udel.edu> <48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il>
In-Reply-To: <48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il>
X-SA-Exim-Connect-IP: 128.4.40.12
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: mills@udel.edu
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail2.ntp.org)
Subject: Re: [ntpwg] question regarding RFC 5907
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <https://lists.ntp.org/pipermail/ntpwg>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9076414501997973934=="
Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org

This is a multi-part message in MIME format.
--===============9076414501997973934==
Content-Type: multipart/alternative;
	boundary="------------030004020708050006080205"

This is a multi-part message in MIME format.
--------------030004020708050006080205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Yaakov and others,

There may be some misunderstanding here. There are literally dozens of 
parameter that can be changed using ntpq, all of them carefully chosen 
to avoid instability. The poll interval can be limited to any range 
within 8s and 36 h. Associations mobilized from a configuration file or 
upon arrival of a packet can also be mobilized or changed with ntpq. 
However, certain things like the damping factor of the impulse response 
cannot be changed. The next anticipated toy is to allow such changes 
using a fuzzy controller that clamps overshoot.

The NTP control/monitoring protocol began life in the early 1980s and 
first appeared in RFC 1305 in 1992. The design was very much in the 
spirit of protocols such as ftp, smtp, http and other early Internet 
adventures. A user can interact using telnet or a purpose-designed 
management protocol like ntpq. The NTP model departs from the telnet 
model, since it uses UDP, but the principle is the same - send ASCII 
strings and expect ASCII strings in response. In the design named 
variables can be read and written and certain canned billboards can be 
produced.

There is in principle no reason why all this could be rebuilt using snmp 
MIB communicating in ASN.1 syntax. The real problem, however, is the 
limited number of data types in SNMP. Just as the units in NASA space 
missions are km, kg and s, the units in ntpq are in ms and fraction, PPM 
and fraction and precision, resolution and interval units in powers of 
two in seconds. It is intended that the ntpq data be parsable using 
convenient Unix tools and many have actually done that.

The design of the MIB could be improved by considering a top-down 
approach and what is intended in the monitoring function. For both 
servers and clients, the fundamental bottom line is how well the 
contraption is working, which needs only the NTP datestamp at the last 
update and the offset, root delay, root dispersion and system jitters at 
that date. If a client, the data for each server surviving the cluster 
algorithm might be useful. There is no real need for the unselectables 
or falsetickers. From these, the estimated clock offset, estimated error 
relative to that offset (jitter) and maximum error due all causes (root 
dispersion plus one-half root delay) can be determined. At this level, 
stratum, mode and poll interval are not that important. Casual watcher 
really don't need anything else, unless poking around for broken things.

The MIB has a number of packet counters, which is a good thing, but 
maybe overdone. Servers and clients don't really care about packet mode 
and stratum, only the number of packets gazinna, gazoutta gadroppa 
packets. The reference implementation is intricately concerned about the 
gadroppas as a debugging tool, but the number different counters has 
varied over the years. For casual monitoring, only the authentication 
failure, access denied and rate exceeded (KoD) counters are really 
significant.

The MIB  calls out a number of notifications (called traps in ntpd), 
some of which are quite specific. These tend to change from time to 
time, currently defined in the ntpq documentation and the status words 
and event messages page. Rather than cast these in concrete, the trap 
includes a short text alert message along with a code that directs the 
user to the relevant documentation. The intent of the traps is for the 
monitoring station to watch for the big ones and text to the sysadmin 
via  cellphone.

 From a management point of view, the most important indicators are the 
system status word and the status word for each association as revealed 
in the documentation. The association status word reveals the selection 
status (tally code) and last event message code. Much more useful 
operational detail is available in the flash code for each association. 
Again, these codes direct the user to the relevant documentation. From 
almost thirty years of watching NTP rascals, that's all I need for the 
gauges on the monitor screens.

The MIB refers to a heartbeat function, presumably so some manager can 
make sure the service is still alive and functioning. The reference 
implementation includes a set of statistics called sysstats, which are 
updated at hourly intervals. These are intended for operators such as 
NIST and USNO to monitor the packet flux. While not done at present, 
these or alternatives could be sent as traps.

Dave

Yaakov Stein wrote:

>Dave, 
>
>Thanks for the response.
>
>Yes, I realize that changing values of parameters requires care
>and, perhaps more importantly, understanding.
>
>However, I can change a broad range of variables in my present
>frequency distribution implementations (based on TDM PWs or 1588),
>including relatively sensitive ones such as packet rates,
>filter bandwidths, thresholds for constant delay change detection, 
>various Kalman filter parameters, etc.
>
>This feature is extremely useful as the same algorithm may be called
>upon to run in many different scenarios, e.g., a large number of 
>network elements that are typically not very highly loaded (i.e. Gaussian PDV),
>a small number of more heavily loaded ones (i.e., with delta function at minimum delay),
>a single switch with other high-rate synchronous flows, etc.
>
>The standard way such configuration is handled is via a management station
>over the network with SNMP. Yes, I realize that NTP was born in another
>type of environment, where other modes of configuration 
>(or even simply recompilation) are prevalent; 
>but it is being used in service provider networks, and this kind of management is needed.
>
>I would appreciate hearing what modifications of NTP behavior
>are easy using ntpq but awkward or impossible using SNMP.
>
>Y(J)S
>
>
>
>-----Original Message-----
>From: David L. Mills [mailto:mills@udel.edu] 
>Sent: Wednesday, August 25, 2010 05:22
>To: Yaakov Stein
>Cc: NTP Working Group
>Subject: Re: [ntpwg] question regarding RFC 5907
>
>Yaakov,
>
>Engineering parameters like MINPOLL and others establish ranges over 
>which the algorithms are intended to work reliably. The hardcoded 
>defines cannot be changed unless all engineering considerations have 
>been explored. In the case (only) of MINPOLL, and as the result of the 
>rate management improvements, MINPOLL has been reduced to 8 s from the 
>former 16 s. Any attempt to lower this number will result in clock 
>feedback loop instability. The preferred way to control the poll 
>interval is using ntpq and the configuration commands.
>
>There are zillions of ways to monitor and/or modify ntpd behavior in 
>legitimate ways using ntpq and ntpdc, most of which are awkward or 
>impossible with presents SNMP. Floating around here somewhere is a SNMP 
>agent designed to interface with the NTP monitoring and control protocol 
>first implemented in 1981. There are at present no plans to support SNMP 
>directly in ntpd.
>
>Dave
>
>Yaakov Stein wrote:
>
>  
>
>>NTP experts, 
>>
>>The NTPv4 MIB RFC starts with the following sentence
>>  The NTPv4 MIB module is designed to allow Simple Network Management
>>  Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
>>  entities.
>>
>>While I see the monitoring elements, I do not see the management (i.e. configuration) ones.
>>
>>In particular, RFC 5905's global parameters are all in #defines in the Appendix,
>>rather than being configurable via the MIB.
>>
>>For example, I would like to be able to change MINPOLL or MINDISP
>>    
>>
>>from a management entity instead of having to recompile.
>  
>
>>I am obviously not the only one who sees an advantage to changing these 
>>as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
>>while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.
>>
>>ooops!!
>>
>>
>>Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
>>Perhaps it was considered better to use netconf ;) 
>>
>>
>>Y(J)S
>>
>>
>>_______________________________________________
>>ntpwg mailing list
>>ntpwg@lists.ntp.org
>>http://lists.ntp.org/listinfo/ntpwg
>> 
>>
>>    
>>
>
>  
>


--------------030004020708050006080205
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yaakov and others,<br>
<br>
There may be some misunderstanding here. There are literally dozens of
parameter that can be changed using ntpq, all of them carefully chosen
to avoid instability. The poll interval can be limited to any range
within 8s and 36 h. Associations mobilized from a configuration file or
upon arrival of a packet can also be mobilized or changed with ntpq.
However, certain things like the damping factor of the impulse response
cannot be changed. The next anticipated toy is to allow such changes
using a fuzzy controller that clamps overshoot.<br>
<br>
The NTP control/monitoring protocol began life in the early 1980s and
first appeared in RFC 1305 in 1992. The design was very much in the
spirit of protocols such as ftp, smtp, http and other early Internet
adventures. A user can interact using telnet or a purpose-designed
management protocol like ntpq. The NTP model departs from the telnet
model, since it uses UDP, but the principle is the same - send ASCII
strings and expect ASCII strings in response. In the design named
variables can be read and written and certain canned billboards can be
produced.<br>
<br>
There is in principle no reason why all this could be rebuilt using
snmp MIB communicating in ASN.1 syntax. The real problem, however, is
the limited number of data types in SNMP. Just as the units in NASA
space missions are km, kg and s, the units in ntpq are in ms and
fraction, PPM and fraction and precision, resolution and interval units
in powers of two in seconds. It is intended that the ntpq data be
parsable using convenient Unix tools and many have actually done that.<br>
<br>
The design of the MIB could be improved by considering a top-down
approach and what is intended in the monitoring function. For both
servers and clients, the fundamental bottom line is how well the
contraption is working, which needs only the NTP datestamp at the last
update and the offset, root delay, root dispersion and system jitters
at that date. If a client, the data for each server surviving the
cluster algorithm might be useful. There is no real need for the
unselectables or falsetickers. From these, the estimated clock offset,
estimated error relative to that offset (jitter) and maximum error due
all causes (root dispersion plus one-half root delay) can be
determined. At this level, stratum, mode and poll interval are not that
important. Casual watcher really don't need anything else, unless
poking around for broken things.<br>
<br>
The MIB has a number of packet counters, which is a good thing, but
maybe overdone. Servers and clients don't really care about packet mode
and stratum, only the number of packets gazinna, gazoutta gadroppa
packets. The reference implementation is intricately concerned about
the gadroppas as a debugging tool, but the number different counters
has varied over the years. For casual monitoring, only the
authentication failure, access denied and rate exceeded (KoD) counters
are really significant.<br>
<br>
The MIB&nbsp; calls out a number of notifications (called traps in ntpd),
some of which are quite specific. These tend to change from time to
time, currently defined in the ntpq documentation and the status words
and event messages page. Rather than cast these in concrete, the trap
includes a short text alert message along with a code that directs the
user to the relevant documentation. The intent of the traps is for the
monitoring station to watch for the big ones and text to the sysadmin
via&nbsp; cellphone.<br>
<br>
>From a management point of view, the most important indicators are the
system status word and the status word for each association as revealed
in the documentation. The association status word reveals the selection
status (tally code) and last event message code. Much more useful
operational detail is available in the flash code for each association.
Again, these codes direct the user to the relevant documentation. From
almost thirty years of watching NTP rascals, that's all I need for the
gauges on the monitor screens.<br>
<br>
The MIB refers to a heartbeat function, presumably so some manager can
make sure the service is still alive and functioning. The reference
implementation includes a set of statistics called sysstats, which are
updated at hourly intervals. These are intended for operators such as
NIST and USNO to monitor the packet flux. While not done at present,
these or alternatives could be sent as traps.<br>
<br>
Dave<br>
<br>
Yaakov Stein wrote:
<blockquote
 cite="mid48E7911F78327A449A9FB95637667286A393F52B@exrad4.ad.rad.co.il"
 type="cite">
  <pre wrap="">Dave, 

Thanks for the response.

Yes, I realize that changing values of parameters requires care
and, perhaps more importantly, understanding.

However, I can change a broad range of variables in my present
frequency distribution implementations (based on TDM PWs or 1588),
including relatively sensitive ones such as packet rates,
filter bandwidths, thresholds for constant delay change detection, 
various Kalman filter parameters, etc.

This feature is extremely useful as the same algorithm may be called
upon to run in many different scenarios, e.g., a large number of 
network elements that are typically not very highly loaded (i.e. Gaussian PDV),
a small number of more heavily loaded ones (i.e., with delta function at minimum delay),
a single switch with other high-rate synchronous flows, etc.

The standard way such configuration is handled is via a management station
over the network with SNMP. Yes, I realize that NTP was born in another
type of environment, where other modes of configuration 
(or even simply recompilation) are prevalent; 
but it is being used in service provider networks, and this kind of management is needed.

I would appreciate hearing what modifications of NTP behavior
are easy using ntpq but awkward or impossible using SNMP.

Y(J)S



-----Original Message-----
From: David L. Mills [<a class="moz-txt-link-freetext" href="mailto:mills@udel.edu">mailto:mills@udel.edu</a>] 
Sent: Wednesday, August 25, 2010 05:22
To: Yaakov Stein
Cc: NTP Working Group
Subject: Re: [ntpwg] question regarding RFC 5907

Yaakov,

Engineering parameters like MINPOLL and others establish ranges over 
which the algorithms are intended to work reliably. The hardcoded 
defines cannot be changed unless all engineering considerations have 
been explored. In the case (only) of MINPOLL, and as the result of the 
rate management improvements, MINPOLL has been reduced to 8 s from the 
former 16 s. Any attempt to lower this number will result in clock 
feedback loop instability. The preferred way to control the poll 
interval is using ntpq and the configuration commands.

There are zillions of ways to monitor and/or modify ntpd behavior in 
legitimate ways using ntpq and ntpdc, most of which are awkward or 
impossible with presents SNMP. Floating around here somewhere is a SNMP 
agent designed to interface with the NTP monitoring and control protocol 
first implemented in 1981. There are at present no plans to support SNMP 
directly in ntpd.

Dave

Yaakov Stein wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">NTP experts, 

The NTPv4 MIB RFC starts with the following sentence
  The NTPv4 MIB module is designed to allow Simple Network Management
  Protocol (SNMP) to be used to monitor and manage local NTP [RFC5905]
  entities.

While I see the monitoring elements, I do not see the management (i.e. configuration) ones.

In particular, RFC 5905's global parameters are all in #defines in the Appendix,
rather than being configurable via the MIB.

For example, I would like to be able to change MINPOLL or MINDISP
    </pre>
  </blockquote>
  <pre wrap=""><!---->&gt;from a management entity instead of having to recompile.
  </pre>
  <blockquote type="cite">
    <pre wrap="">I am obviously not the only one who sees an advantage to changing these 
as in Figure 6 MINPOLL defaults to 16 seconds and MINDISP to 0.01
while in the code MINPOLL is set to 64 seconds and MINDISP to 0.01.

ooops!!


Can someone explain the design considerations that led to leaving these out of the 5907 MIB ?
Perhaps it was considered better to use netconf ;) 


Y(J)S


_______________________________________________
ntpwg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ntpwg@lists.ntp.org">ntpwg@lists.ntp.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ntp.org/listinfo/ntpwg">http://lists.ntp.org/listinfo/ntpwg</a>
 

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

--------------030004020708050006080205--

--===============9076414501997973934==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg
--===============9076414501997973934==--