Re: [Last-Call] Genart last call review of draft-ietf-ntp-chronos-14

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

 



Hi Neta
Thanks see inline

On Tue, 13 Jun 2023 at 23:43 Neta R S <neta.r.schiff@xxxxxxxxx> wrote:
Hi Roni,

Thanks for your feedback!
Please see my response inline (in blue).

Best,
Neta

On Mon, Jun 12, 2023 at 7:55 PM Roni Even via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-ntp-chronos-??
Reviewer: Roni Even
Review Date: 2023-06-12
IETF LC End Date: 2023-06-22
IESG Telechat date: Not scheduled for a telechat

Summary: the document is almost ready for publication as an informational RFC

Major issues:

Minor issues:
1. I am not sure how chronos user leave panic mode?
>> "Panic mode" represents a condition in the code which results with a high number of queries at a given interval. 
In the next interval, the client will start by making a small number of queries, regardless of previous panic. 
Note that arriving in a panic mode is very unlikely and consecutive intervals with panic mode are much more.
I will add a clarification for that at the end of section 3.2 in a new draft version. 

Roni:OK


2. How does chronos work when a media receiver need to synchronize between
different media sources  where some use chronos and some not. For example if
one of the sources is in panic mode.
It's correct that if there's an attack on the ntp region where the media endpoints (sources and receiver) exist then there will be a time difference between the protected to the unprotected endpoints.
However, similar and possibly bigger differences will happen when no endpoint is protected by chronos and the attack affects only part of the endpoints and/or has a different impact on each endpoint.

Roni: maybe it should be mentioned in section 6 as part of the precision recommendations


Nits/editorial comments:


-- 
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