14c14
< <!-- #BeginDate format:En2m -->17-May-2016 06:26<!-- #EndDate -->
---
> <!-- #BeginDate format:En2m -->9-Nov-2016 12:26<!-- #EndDate -->
148c148
< <dt id="tos"><tt>tos [beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
---
> <dt id="tos"><tt>tos [bcpollbstep <i>poll-gate</i> | beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
151a152,153
> <dt><tt>bcpollbstep <i>poll-gate</i></tt></dt>
> <dd>This option will cause the client to delay believing backward time steps from a broadcast server for <tt>bcpollbstep</tt> poll intervals. NTP Broadcast networks are expected to be trusted, and if the server's time gets stepped backwards then it's desireable that the clients follow this change as soon as possible. However, in spite of various protections built-in to the broadcast protocol, it is possible that an attacker could perform a carefully-constructed replay attack and cause clients to erroneously step their clocks backward. If the risk of a successful broadcast replay attack is greater than the risk of the clients being out of sync in the event that there is a backward step on the broadcast time servers, this option may be used to cause the clients to delay beliveving backward time steps until <i>poll-gate</i> consecutive polls have been received. The default is 0, which means the client will accept these steps upon receipt. Any value from 0 to 4 can be specified.</dd>
< <!-- #BeginDate format:En2m -->17-May-2016 06:26<!-- #EndDate -->
---
> <!-- #BeginDate format:En2m -->9-Nov-2016 12:26<!-- #EndDate -->
148c148
< <dt id="tos"><tt>tos [beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
---
> <dt id="tos"><tt>tos [bcpollbstep <i>poll-gate</i> | beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> | orphanwait <em>delay</em>]</tt></dt>
151a152,153
> <dt><tt>bcpollbstep <i>poll-gate</i></tt></dt>
> <dd>This option will cause the client to delay believing backward time steps from a broadcast server for <tt>bcpollbstep</tt> poll intervals. NTP Broadcast networks are expected to be trusted, and if the server's time gets stepped backwards then it's desireable that the clients follow this change as soon as possible. However, in spite of various protections built-in to the broadcast protocol, it is possible that an attacker could perform a carefully-constructed replay attack and cause clients to erroneously step their clocks backward. If the risk of a successful broadcast replay attack is greater than the risk of the clients being out of sync in the event that there is a backward step on the broadcast time servers, this option may be used to cause the clients to delay beliveving backward time steps until <i>poll-gate</i> consecutive polls have been received. The default is 0, which means the client will accept these steps upon receipt. Any value from 0 to 4 can be specified.</dd>