> On Jun 4, 2015, at 2:29, Tom Yates <[email protected]> wrote: > > I run a pool server, and my understanding was that vendors weren't supposed > to do this.
Yes. > Is there any kind of procedure for dealing with this? Or should i just > ignore it? You writing to their support, your sales rep or similar with the http://www.pool.ntp.org/vendors/ website and telling them that they are using a free service inappropriately would be appreciated (and appropriate, I think). I’ve done some variation of it from time to time but not being a customer usually I get nowhere and it just leave me bothered about it. :-) I do have a legal-sounding letter template from a lawyer I could send, but I think the trade-offs are more complicated here. I’ll try typing out some of the considerations — you’ll hopefully agree that it’s not super straight forward. We need to balance meeting the goal of the project (provide service for everyone!) with the health of the project (a service that actually works!). 1) The main benefit of vendors using a vendor pool is that we have at least a theoretical mitigation for their queries if they go “rogue”. 2) The other benefit is that it gives us a (brief) window of opportunity to educate and do some basic sanity checking with the vendor. I spent quite a bit of time on this (though not enough). 3) Often I try to discourage (large) vendors from using the pool. Basically making it clear that there’s a cost (to someone) no matter what they do so they’ll be better off setting up their own infrastructure. We can be the “default service”, but not the only one. 4) Some vendors pay for their vendor pool and this covers what I spend on hosting, ARIN, servers, etcetera. I try to conservatively adjust the costs/investments to best serve the pool project long term. 5) The project is rooted in “open source”, but even that is complicated. Some open source vendors are large enterprises with commercial products. Some network device vendors have really terrible NTP implementations (expensive in terms of resources for both the DNS and NTP parts of our project), but much of their “stack” might be open source. Mostly I try encouraging those to have their own infrastructure when I get the chance. 6) To really mitigate (or even detect!) a rogue vendor (see 1) above) there’s a bunch of not yet done development work to do (and more costs). 7) The intention of the NTP Pool as Adrian set it up is, I believe, to be the default NTP server for the internet. If we aggressively send people away they’ll just as likely just bombard the NIST time servers or similar instead. “Better us than them”. 8) Considering the history and current status (see 4 and 7 above) it doesn’t seem appropriate to more aggressively get vendors to help financially or even with infrastructure. Again, better us than NIST or some university stratum 1 server. Though again, even better would be if they setup their own systems. Smaller vendors I try to get to at least add a server or two to the pool. If that makes up for their "resource use”, I’ve no idea. 9) Probably most of our resources (DNS, NTP and time) goes to crappy implementations from people who didn’t consider any of this; so just the act of them signing up for a vendor pool and hopefully reading the documentation we have (patches welcome!) makes us as a project much better off. 10) So, considering 9), yes — please encourage them to sign up for a vendor zone. :-) Ask _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
