| Without wanting to be
overly contrarian on this--NTP being a prime example of a protocol where
people have strongly felt opinions--this draft as it stands provides a
pretty good basic set of practices which are immediately relevant for
the vast majority of people inclined to look at deploying NTP. The questions that Joe raises about its suitability for purpose comes down to the document's intended audience. There is no doubt that the document is of questionable suitability for organisations or people who have a hard requirement for high precision, guaranteed quality timekeeping, e.g. reference or legal timekeeping. However, there is equally little doubt that if most people who ran NTP services adhered to most of the recommendations listed in the draft, that NTP quality in the world would increase overall, probably dramatically. My understanding is that the term "BCP" refers to the latter category of people rather than to the former, i.e. "best common practice" rather than "practice which which is provably consistent with a carefully defined and very specific set of inputs with consequently expected output results". Regardless of intention, it's not going to be helpful to suggest that Jimbob's Bait and Tackle get their IT monkey to deploy 6 meinbergs using a mixture of gps and dcf77 and then set up a committee to create a set of recommendations on auth key deployment. Conversely, what would be useful would be a clear statement in the document about its intended audience, i.e. where the recommendations in this draft are relevant, and more importantly, where they are not suitable for purpose. Tom Petch's suggestions are useful - there are several areas where the language could be tightened up and tidied, and it would help to have an -08 version with not just this taken on board, but also a general stylistic edit because the language is genuinely too colloquial if not a bit sloppy in places. On the leap smearing issue, some people are going to do it, and most people won't. It's not useful for the IETF to pretend it doesn't happen or castigate people for using it; we don't run other people's systems and don't have to deal with their arrays of embedded devices which are locked to a specific kernel version which crashes every time ntp jumps forward by one second. Also, we have no real visibility into what would happen to any specific organisation if a negative leap second were declared, but I suspect a lot of trouble, and a lot more trouble than if leap smearing were implemented within specific admin domains. Anyway, rant over - it's fine to say "SHOULD NOT" within your own admin domain, and "MUST NOT" for interfaces to others, and have a discussion about the mechanism in general (which is mostly there). Nick
|
