Subject: Re: [Ntp] EXTERNAL: Re: [TICTOC] WGLC for draft-ietf-ntp-mode-6-cmds

From: "[email-masked]" <[email-masked]>
Date: Sat, 16 Jun 2018 09:19:22 +0300

What is the difference between eyeball/wristwatch and "serial interrupt source", mechanically they are the same process. 

As to metadata tracking of the time source that us more tied to legal issues imho. It should remain.

//TSG

Sent from my HTC, so please excuse any typos this keyboard sucks!

----- Reply message -----
From: "Harlan Stenn" <[email-masked]>
To: "Alex Campbell" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Karen O'Donoghue" <[email-masked]>
Subject: [Ntp] EXTERNAL: Re: [TICTOC] WGLC for draft-ietf-ntp-mode-6-cmds
Date: Fri, Jun 15, 2018 21:18

Yes, clock source type 8 is real. It was more relevant 30 years ago, but it’s still a choice. Sysplex. 

If clock sources are not defined, there is no way to track or lookup the metadata. 

More from me on these and your other points later. 

Sent from my iPhone. Please excuse brevity and typos.

> On Jun 13, 2018, at 4:06 PM, Alex Campbell <[email-masked]> wrote:
> 
> Hi,
> I've reviewed this document and I have the following issues:
> 
> * Clock source value 8 ("eyeball-and-wristwatch") - is this a serious value? If the time server is synchronized to a wristwatch which is not synchronized to any other source, I would think the correct value is "unspecified/unknown".
> * Clock source values should not be defined in a fixed lookup table. There are a number of other possible clock sources (such as IEEE 1588v2, Building Integrated Timing Supply, an unsychronized local clock, or a video camera pointed at a sundial) and it is not possible to cover every conceivable clock source in 6 bits. I can understand that the 6-bit code might still be required for backward compatibility, but there should also be a variable which can specify more details (such as the exact name of the radio station being used)
> * Likewise for the error code ("Clock Code") in the clock status word. For example I would expect a GPS-sourced clock with a poorly-placed antenna to be able to return a status message such as "Not enough satellites in view."
> * Please clarify whether the System Event Counter resets to 0 when an event occurs which has a different event code from the preceding event.
> * Likewise for the Peer Event Counter, and the event counter in the Clock Status Word. 
> * Please clarify where whitespace can be added (and MUST be ignored by the recipient) in a command data field, and where it is significant (and MUST NOT be ignored).
> * Please clarify whether whitespace is ignored in response data in a similar manner.
> * Please clarify which characters are considered whitespace. (I take "ASCII nonprinting format effectors" to include backspace, horizontal tab, vertical tab, linefeed, carriage return and form feed)
> * In a Read Status (1) response with zero as the association identifier, how are the entries delimited from each other, and how is the association identifier delimited from the status word within an entry?
> * In a Read Variables (2) command, the command data field may be a list of identifiers, but the draft doesn't specify that this list has any effect. Is it meant to filter the returned variables?
> * Set Trap Address/Port (6) - how long is a lengthy interval?
> * Read MRU (10) - how is the nonce returned in the response?
> * Read MRU (10) - which variables are returned in the response data?
> * Read MRU (10) - please clarify that the response data format is the same as for Read Variables (if this is actually the case).
> * Read MRU (10) - how does the command data affect the response?
> * Read ordered list (11) - what is the format of the response data?
> * Should NTP control requests from the public Internet be processed by a server, or should the use of them be generally restricted to authorized administrators?
> * Appendix A - why must the data area for a request be exactly 40 octets in length? Surely this would be server-specific.
> * Appendix A - can requests also be fragmented?
> * Why are there two distinct protocols (one not standardized) for server monitoring and configuration? (Control and Remote Facility)
> 
> Alex
> 
> ________________________________________
> From: TICTOC <[email-masked]> on behalf of Karen O'Donoghue <[email-masked]>
> Sent: Wednesday, 13 June 2018 9:46 p.m.
> To: [email-masked]
> Cc: [email-masked]
> Subject: EXTERNAL: Re: [TICTOC] WGLC for draft-ietf-ntp-mode-6-cmds
> 
> Folks,
> 
> Please respond to this WGLC. The deadline is Friday!
> 
> Karen
> 
>> On May 31, 2018, at 5:26 AM, Karen O'Donoghue <[email-masked]> wrote:
>> 
>> Folks,
>> 
>> This begins a 2 week working group last call for the following document:
>> 
>> Control Messages Protocol for Use with Network Time Protocol Version 4
>> https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/
>> 
>> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed.
>> 
>> Please send all comments in by Friday 15 June 2018.
>> 
>> Thank you!
>> Karen and Dieter
> 
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp