[ntpwg] KISS codes

[David L. Mills]

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.

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

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.

Dave

Danny Mayer wrote:

> Harlan Stenn wrote:
>
>> Karen,
>>
>>> I was wondering about this issue earlier today as I was working through
>>> all the comments received. My question is based on other discussions on
>>> this mailing list related to whether or not we are representing
>>> current practice.
>>
>> I believe Danny's change does not represent current practice.
>
>
> Correct. Certainly the reference implementation doesn't implement it but
> that shouldn't prevent us adding it to the RFC and we really should
> implement this no matter what happens to the standard.
>
>> The problem is that current practice is ... lame (at best) in this
>> regard and there needs to be, IMO, a way for a server to tell clients to
>> "go away" where there is better instruction that the clients really
>> should listen and do what it is told.
>>
>>> Along that vein, would it make sense to change
>>> "MUST" to "SHOULD" in Danny's proposed text? I can go either way
>>> but I was struggling with identifying the consensus...
>>
>> SHOULD could be arguably better, and if that's the way we go I expect
>> that RSN we'll want to upgrade that word to a MUST.
>>
>
> Revisiting RFC's is hard and takes a long time. Put it into the
> standards now as a MUST and we have a chance of getting people to
> implement it. Make it a SHOULD means that it will never happen as it is
> after all extra code that needs to be written.
>
>> And I would love to hear back from more folks on this one, as I suspect
>> that MUST really is the right way to go.
>>
>> But if we're gonna make a change here, I can see the reason for taking
>> the conservative approach first.
>>
>
> I don't know which approach you consider to be conservative here.
>
> Danny
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg


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