Subject: [ntpwg] exposed data

From: Harlan Stenn <[email-masked]>
Date: Fri, 14 Dec 2007 01:42:33 +0000

ntpd can expose a fair bit  of information about its state.

The mode 6 packets can do a lot of this already.

In the reference implementation, ntpq (which uses mode 6 packets, as
opposed to ntpdc, which uses mode 7 packets) can expose a fair amount of
data.

Some of this data is arguably generic information that would be implemented
by anybody doing an NTP implementation, and some of this data is arguably
implementation-specific data.

To what extent should we identify where on the continuum between
"implementation-specific" and "MUST implement" the bits of data exposed by
the reference implementation fall?

To what extent should the mode 6 protocol "handle" these various bits of
data?

At what, if any, point do we want to standardize any of these items?

I know I am asking some questions that have been already addressed, at least
in some way.

It just seems to me that we haven't achieved any useful resolution on this
topic, at least based on the several open reports I have in my ntp bugzilla
queue.

I'm also not suggesting we resolve these points before the V4 spec is
finalized.  But I do believe we must address and resolve this issue.
-- 
Harlan Stenn <[email-masked]>
http://ntpforum.isc.org  - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 14 Dec 2007 02:39:31 +0000

Harlan,

The mode-6 protocol itself is not an issue; it just reveals what the 
server sends. The ntpq program, which just lights up what is revealled 
by the server, is not an issue. The ntpq program should never reveal 
data on its own, which is why the flash decodes are so contentious. 
These decodes use local interpretation which can be at odds with the 
documentation and server design. This violates my original design which 
required using only the data the server sends. If decodes are needed, 
the server should send them.

The ntpq program, protocol and server revelations were never intended to 
be standardized. The program was and is used as a diagnostic, the 
details of which can be adjusted and/or expanded from time to time, 
especailly as new features like orphan and Autokey are implemnted and 
tested. The program should be flexible and usable, even with warts.

Your mission has absolutely no legs in the context of the protocol, ntpq 
or revealled informatio. It has absolultely brilliant legs for the MIB 
mission and should be seriously discussed in that context.

Dave

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 14 Dec 2007 02:58:03 +0000

Dave,

> required using only the data the server sends.

Works for me.

> If decodes are needed, 

I will begin the steps to see that this is how it works.

H

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Dec 2007 00:22:36 -0500

> mission and should be seriously discussed in that context.

I agree.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 19 Dec 2007 06:27:24 -0800

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "David L. Mills" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 18, 2007 9:22 PM
Subject: Re: [ntpwg] exposed data

>> data on its own, which is why the flash decodes are so contentious.

Why not?

>> documentation and server design.

Sure but that is a key part of being able to audit the code.

> > This violates my original design which

The there would need to be a method of making that happen which doesnt exist 
now.

>> be standardized.

Then remove it from the package since NO code which is not standardized 
should be included in the distribution.

>> The program was and is used as a diagnostic, the
>> tested.

Yes but its functionality needs to be formally documented and tested with 
any release.

>> The program should be flexible and usable, even with warts.
>>

---

From: Hal Murray <[email-masked]>
Date: Wed, 19 Dec 2007 10:55:57 -0800

[email-masked] said:
> Then remove it from the package since NO code which is not
> standardized should be included in the distribution. 

That doesn't make sense to me.

First off, we aren't standardizing any code.  It's a reference implementation.

Second, if I get a package of code, I'd like to get related utilities and 
hacks too.  Sure, it's better if they work correctly and even better if they 
are high quality.  But if I'm chasing a glitch, I'd rather start with a hack 
that's leftover from when somebody else was chasing a similar glitch than 
nothing at all.

Yes, there should be some indication of the quality of hacks so expectations 
are correct.

> Yes but its functionality needs to be formally documented and tested
> with any release. 

I'm happy with the documentation for ntpq.  I see no reason to standardize it.

Do you think we should standardize the sample config files that are included in the distribution?  :)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.