[ntpwg] KISS codes

[David L. Mills]

Danny,

I beg to differ. The client side does respond to DENY; but, as I said in 
a previous message, it doesn't make sense to respond to RATE, as the 
server side is so conservative. On the other hand, it is in principle 
possible to evoke RATE in the present implementation if the client 
configures burst mode with a poll interval of 16 or 32 s. Is that what 
you had in mind? That's easy to fix by putting limits in the 
configuration' I set the parameters so that it would be possible to test 
the server response.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
>
>> Guys,
>>
>> For record, the ntp-dev stops sending packets under conditions where
>> resending is guaranteed to be unsuccessful; in particular with kisscode
>> DENY. A client kissed with that code should go on-hook immediately.
>
>
> That means that at least the server is sending them. The client side of
> the reference implementation does not do anything with the codes as yet
> as far as I recall. It's well worth implementing.
>
>> It doesn't make a lot of sense for the program to do anything for RATE,
>> as the program cannot send at rates likely to set off such a code. It
>> does back off eventually to 1024 s.
>
>
> The reference implementation does, but this is meant to address other
> implementations. This reminds me that I should go back and take a look
> at what the draft says about the frequency of sending NTP request
> (client) packets and make sure that's a strong statement.
>
>> But, the real monster can be a
>> misguided implementation in 750,000 routers. See:
>> http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf.
>>
>
> And that's what these recommendations are designed to start addressing.
> It will never fix the problem and the only thing we can do about it is
> yell "non-RFC compliant" as the network compliance police is always on
> coffee break. What it DOES do is to give any victim ammunition to sue
> the pants off the errant manufacturer and that is a much more viable goal.
>
>> I will guarantee this situation will occur soon in a router designed and
>> built in China by a Mandarin speaker that has read neither RFC 4330 nor
>> the forthcoming NTPv4 specification. RFC 4330 had a lot of stuff
>> intended as best practices for a NTP client. I fear much of this will be
>> lost should that document be deprecated by the spec.
>>
>
> In that case we should not deprecate RFC 4330. or incorporate parts of
> it in this draft or provide a BCP document to replace it.
>
> Danny


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