[ntpwg] Additional text for SNTP

[David L. Mills]

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:

> 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
>
> ----- Original Message ----- From: "David L. Mills" <mills at udel.edu>
> Cc: "NTP Working Group" <ntpwg at lists.ntp.isc.org>
> Sent: Friday, March 28, 2008 12:27 PM
> Subject: Re: [ntpwg] Additional text for SNTP
>
>
>> 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
>>
>> Greg Dowd wrote:
>>
>>> 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=symmetricom.com at lists.ntp.org
>>> [mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] 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,
>>>
>>> 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
>>>
>>> Danny Mayer wrote:
>>>
>>>> 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
>>>> ntpwg at lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwg at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>>
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg 
>
>