Subject: [ntpwg] Additional text for SNTP

From: Danny Mayer <[email-masked]>
Date: Thu, 27 Mar 2008 22:53:05 -0400

I'd like to propose additional text be added to section 14 on SNTP in 
the NTPv4 protocol draft. I'm requesting this addition due to an issue 
that came up last week with an SNTP client.

Suggested text:

"An SNTP client MUST only send mode 3 packets (client) and MUST only 
accept mode 4 (server) and mode 5 (broadcast) packets. An SNTP client 
MAY send or receive mode 6 (NTP control) packet. All other packet modes 
MUST be ignored.

An SNTP server MUST not send mode 3 (client) packets."

Any objections or refinements?

Danny
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Brian Utterback <[email-masked]>
Date: Fri, 28 Mar 2008 09:10:06 -0400

> An SNTP server MUST not send mode 3 (client) packets."

Could you explain the intent to me, because the wording you used seems 
contradictory. The first sentence says that a SNTP client must send 
only one type of packet and the second sentence says that it is okay 
for a SNTP client to send another type as well. If the second 
paragraph is true, then doesn't that mean that all SNTP servers must 
have a refclock?

-- 
blu

There are two rules in life:
Rule 1- Don't tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Brian Utterback <[email-masked]>
Date: Fri, 28 Mar 2008 13:55:26 -0400

Danny Mayer wrote:
> Brian Utterback wrote:
>>> the NTPv4 protocol draft. I'm requesting this addition due to an 
>>> issue that came up last week with an SNTP client.
>>>
>>> Suggested text:
>>>
>>> MAY send or receive mode 6 (NTP control) packet. All other packet 
>>> modes MUST be ignored.

How about:

An SNTP client MUST only send mode 3 packets (client) and mode 6 
(control) packets.  An SNTP client MUST only accept mode 4 (server), 
mode 5 (broadcast) and mode 6 (NTP control) packets. All other packet 
modes MUST be ignored. An SNTP client MAY send only mode 3 packets and 
accept only mode 4 and 5 packets.

-- 
blu

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 18:28:29 +0000

Danny,

I'm not sure any words are necessary. An SNTP client is ipso facto a 
client and by spec sends only mode-3 messages. We have defined an SNTP 
server and an SNTP client, but not an SNTP peer. Also, I'm a little 
uneasy about saying what an SNTP client can or cannot accept. It can't 
have dependent clients, so in truth we don't care what it does with the 
server packet other than to say if it follows the peer process rules it 
will make good clock.

Dave

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 28 Mar 2008 11:35:58 -0700

Is it actually true in 4330 that a sntp client cannot be a sntp server.
I thought that it said that it was designed to operate at the "edges" of
the network, without a constraint that it couldn't do a stratum2
function explicitly stated.  

I understand the logic, but I believe the addition of text to constrain
operation is a NEW idea for ntpv4.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Friday, March 28, 2008 11:28 AM
To: NTP Working Group
Subject: Re: [ntpwg] Additional text for SNTP

Danny,

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 19:27:10 +0000

Greg,

(Shudder) It was never the intent to allow an SNTP client to have 
dependent clients. I had assumed the word "edge" implied specifically 
that. I did wordsmith carefully in the NTPv4 spec to differentiate 
primary server, secondary server (with clients) and clients (without 
clients). That means SNTP widgets of whatever stripe cannot function as 
secondary servers.

Dave

---

From: "TS Glassey" <[email-masked]>
Date: Fri, 28 Mar 2008 12:51:14 -0700

David - in response to this - let me clarify for the record here - The 
specific use model for SNTP is then constrained to end-user devices and 
appliances, and its not capable of being used for 'secured' or 'audited' 
time setting's without external telemetry, but that's OK. In fact its better 
for all concerned since it means that the NTP service will get implemented 
now in more places.

Todd

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 28 Mar 2008 20:14:54 +0000

Todd,

Huh? The issue of authentication and/or audit has nothing to do with 
whether NTP or SNTP, nor anything to do with user profile. SNTP servers 
have no upstream servers (and thus must be primary); SNTP clients have 
no downstream clients. Authentication by one means or another is a 
completely separate issue. In fact, the MS-SNTP document describes an 
authenticated client.

Dave

TS Glassey wrote:

> specific use model for SNTP is then constrained to end-user devices 
> and appliances, and its not capable of being used for 'secured' or 
> 'audited' time setting's without external telemetry, but that's OK. In 
> fact its better for all concerned since it means that the NTP service 
> will get implemented now in more places.
>
> Todd
>
> ----- Original Message ----- From: "David L. Mills" <[email-masked]>

---

From: Danny Mayer <[email-masked]>
Date: Fri, 28 Mar 2008 13:30:40 -0400

Brian Utterback wrote:
> contradictory. The first sentence says that a SNTP client must send only 
> one type of packet and the second sentence says that it is okay for a 
> SNTP client to send another type as well.

I'm trying to say that it can only send client queries but it can also 
respond to status queries (which is what mode 6 and 7 do). Can you word 
this better?

  If the second paragraph is
> true, then doesn't that mean that all SNTP servers must have a refclock?
> 

That's exactly what the spec says about SNTP servers.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 28 Mar 2008 17:39:08 -0400

Dave,

The drive to add this came from the aberrent behavior of ws32time. This 
way it is made very clear that a standards conforming SNTP client will 
do the right thing. Specifying the allowed modes of the packets also 
helps people to know what ones to send out and to receive. We cannot 
assume that the Internet standards police when they eventually get off 
their coffee break will shut down the rascals.

Danny