Subject: [ntpwg] WG LAST CALL: draft-ietf-ntp-ntpv4-proto-06.txt

From: karen.odonoghue at navy.mil (Odonoghue, Karen F CIV NSWCDD, W13)
Date: Fri, 8 Jun 2007 11:01:36 -0500

This message initiates a NTP working group last call on the document: 

     Title: Network Time Protocol Version 4 Protocol And 
        Algorithms Specification 
     Filename: <draft-ietf-ntp-ntpv4-proto-06.txt> 

The purpose of this WG last call is to ensure that this 
document is ready to be forwarded to the IESG for approval 
and publication as a Proposed Standard. 

As part of this last call process, we are asking that working 
group members do the following: 

1. Review the document for both technical and editorial 
errors.  Technical issues should be sent to the NTPWG mailing 
list (ntpwg at lists.ntp.org) for discussion and resolution. 
Editorial comments may be sent either to the mailing list or 
directly to the document editor (Jim Martin, jim at daedelus.com). 

2.  Post to the mailing list your position on whether or not 
this document is ready to be forwarded for publication. 

The last call period will last two weeks, ending on Friday,  22 June, 2007. 

Upon completion of the last call, the WG chair(s) will take 
action based upon the consensus of the WG. 

Regards, 
Karen O'Donoghue and Brian Haberman 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070608/8ccaac84/attachment.html

---

From: yaakov_s at rad.com (Yaakov Stein)
Date: Wed, 20 Jun 2007 16:42:22 +0300

First, I would like to state that the readability has greatly improved
in this version 
and to say thanks for fixing the equation for T(t).
 
Although I have one remark and numerous editorial nits  (see below) 
I believe the present version is sufficiently mature
and I fully support this document being sent to the IESG.  
 
Y(J)S

My remark is regarding the units of frequency (this will be more
important in TICTOC).  The standard unit of frequency is the Hz
which is 1 / sec. Since NTP distributes time but does not directly 
distribute frequency, the only way frequency is used here is
via "fractional frequency offset", i.e. the difference between
a frequency and the nominal divided by the nominal. Since this
is the ratio of two frequencies in Hz, it is unitless.
Of course, if something is unitless you can call it sec/sec,
but I believe this to be missleading (actually, Hz/ Hz is better).
So I would prefer something like this -
In this document all time values are in seconds (s),
and all frequencies will be specified as fractional frequency offsets
(FFO)
(pure number). It is often convenient to express these FFOs in parts per
million (ppm).
 
NITS
====
The statement that UTC comes from a source "such as a GPS receiver 
or telephone modem service" still sounds too specific  (and perhaps
outdated)  to me. How about "a source traceable to UTC.  
One readily available source is GPS."   (Of course, Galileo, eLoran,
etc. are also fine).
 
Page 7  "can be mixed and matched"
I understand the "mixed". What has to be matched?
 
Figure 2 - should "Packet Variable" be "Header Variable" ?
 
Page 12  The selection algorithm uses Byzantine principles ... 
I don't think the algorithm is Byzantine, unless it was developed
in the capital of Turkey. I couldn't pull the Marzullo reference either.
Does this statement mean that the algorithm achieves what Lamport
calls "Byzantine agreement", or that it is robust against arbitrary
Byzantine faults?
 
Page 12   These terms are given precise interpretation in Section 11.2.
Can you show me where ?
 
I guess the use of the term "era" vs. the prime "epoch" is too hard
to change. But can we have "prime epoch" explained where it is first
used ? 
 
Figure 5  Year -> Date
 
Page 16  It is important to note that twos-complement arithmetic does
not know ...
I don't believe twos-complement arithmetic knows anything.
How about 
  It is important to note that twos-complement arithmetic does not
distinguish 
  between signed and unsigned values (although comparisons can take sign
into account).
  ... A perceived hazard ... might result in over-run ...
 
Page 16  log to the base 2  ->  log base 2
 
Page 19   The NTP packet header follows the UDP and IP headers and the
physical ...
I guess we have to process this statement in RPN.
How about "The NTP packet header follows the UDP header, 
which itself follows the IP header, which in turn follows a physical ...
 
Figure 9 "Message Digest" - the term MAC is used in all other places
 
Page 21  The header extends from the beginning  - should this be "The
basic header ..."
 
Page 22  conveniently mitigated using the same algorithms (see A.5.5.1)
...
 
Figure 13 - LORAN C 100 KHz -> any LORAN C station, 100 KHz
 
Page 23  and is intended to detect timing loops  - how about "can be
used to detect"
 
Page 28 "is interpreted to mean"  - either "is interpreted" or "taken to
mean"
 
Page 31 it is possible that the delay computation becomes negative ->
it is possible for the delay computation to become negative
 
Page 34  DSCRD. This is a nonfatal ...  ->  DSCRD. This indicates a
nonfatal ...
Or "This step is carried out following ..."
Similarly for the other steps.
 
Page 37  Appendix A.5.2"  - remove quote mark 
 
Page 38 was sent It -> was sent.  
 
Page 38   in the clock_filter() routine in Appendix ...   
can we avoid the double in, for example   in the clock_filter() routine
of Appendix ...
 
Page 42  "the clock discipline algorithm described in Appendix A.5.5.6"
Can we use "coded in Appendix A.5.5.6" or "for which code is provided in
Appendix A.5.5.6"
Similarly for the first line on page 45.
 
page 58  bitsand -> bits and
page 93  discipoine -> discipline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070620/eac36e6a/attachment.html