Re: [Last-Call] Tsvart last call review of draft-ietf-ntp-chronos-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think it needs a copy-edit pass. Not because there's a major issue, but because it mixes the the passive voice and possessive punctuation

On Sat, Jul 1, 2023 at 6:47 PM Neta R S <neta.r.schiff@xxxxxxxxx> wrote:
Hi Tommy,

Thanks for your feedback.
I am sorry for the late response.
Please see my reply inline below (in blue).

Best,
Neta

On Mon, Jun 19, 2023 at 11:16 PM Tommy Pauly via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Tommy Pauly
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.

I have no concerns about this document from the transport perspective. Its use
of DNS queries and NTP transactions has a very low rate (intended to not
overwhelm servers), and doesn't raise any new concerns. This document also
doesn't add any new mechanisms that would affect usage of transport mechanisms,
ports, etc.

The document is clear and concise, although I have two nits for clarity:

- In Section 1, the term "Byzantine attackers" is used without reference or
explanation. Later, it does have a forward reference to the security section. I
suggest adding a forward reference or an external reference to explain the
attack, and potentially add a bit more context within the text to help readers
who are not familiar with that kind of attack.
>> Thanks, I added a forward reference in the introduction.
 
- A block diagram or other
illustration would be much appreciated in section 3 to help explain how the
Khronos function exists alongside current client software, and what servers it
is interacting with. I'm not sure how feasible such an image would be, but I
think it would make the document more easily understood.
>> I agree such a diagram could be useful but also hard to include in the standard. 
I will make sure such a diagram is included in the documentation of the upcoming formal release of the project. 

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux