[ntpwg] KISS codes

[anthony.flavin at bt.com]

Danny,

I don't see how this would work. Especially in the case of SNTP. The
problem you site is where the sheer number of devices polling the server
swamped it. I believe that at the moment an NTP server only stores the
past 600 which is unlikely to be enough to determine who the trouble
makers are, so unless you are proposing to store the last several thousand
requests, how are you going to determine who to send the codes to?

Regards,

	Tony Flavin
	Core Networks Engineering Manager

	e-mail: anthony.flavin at bt.com
	tel: +44(0) 1473 609570
	mobile: +44(0) 7801 759596
	fax: +44(0) 1908 862752

	Orion 5,  pp11 , Adastral Park, Martlesham, Ipswich IP5 3RE, UK



-----Original Message-----
From: ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org
[mailto:ntpwg-bounces+anthony.flavin=bt.com at lists.ntp.org] On Behalf Of
Danny Mayer
Sent: 09 July 2007 15:57
To: Odonoghue, Karen F CIV NSWCDD, W13
Cc: NTP Working Group; Harlan Stenn
Subject: Re: [ntpwg] KISS codes


Odonoghue, Karen F CIV NSWCDD, W13 wrote:
> Danny and Harlan,
>
> 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. 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...
>

My preference here is MUST since revisiting this in a later RFC is much
harder. It's actually easier to change it to SHOULD later. My desire to
see this implemented as a MUST for both NTP and SNTP is the experience
that a number of clock providers have been through where they have been
swamped with unwanted and heavy traffic. If we don't put it in the
standard not only will noone implement it but we will never give the
providers any control over who is querying their servers and how
frequently.

Right now there is no consensus about this either way since it never seems
to have been discussed.

Danny
> Karen
>
>> -----Original Message-----
>> From: ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org
>> [mailto:ntpwg-bounces+karen.odonoghue=navy.mil at lists.ntp.org]
>> On Behalf Of Harlan Stenn
>> Sent: Monday, July 09, 2007 0:15
>> To: mayer at gis.net
>> Cc: NTP Working Group
>> Subject: Re: [ntpwg] KISS codes
>>
>> Danny,
>>
>> In general, I really like your proposal.  I haven't said
>> anything about it because I'm not aware of any reasons it's a
>> bad idea and that concerns me.  I figure there *has* to be
>> some cases where what you describe inappropriate.
>>
>> For how long must a server stop sending packets to the server in this
>> case:
>>
>> a) For kiss codes: DENY, RSTR the client MUST demobilize any
>>    associations to that server and stop sending packets to that
>>    server;
>>
>> Is it a good idea to better define the "reduction" mentioned here:
>>
>> b) For kiss code: RATE the client MUST immediately reduce its polling
>>    interval to that server and continue to reduce it each time it
>>    receives a RATE kiss code.
>>
>> H
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>

_______________________________________________
ntpwg mailing list
ntpwg at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/ntpwg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5938 bytes
Desc: not available
Url : https://lists.ntp.org/pipermail/ntpwg/attachments/20070709/86963699/attachment.bin