Closed davidv1992 closed 1 year ago
Thanks for this contribution, however with regards to the first sentence - this is likely redundant, and I've been trying to steer away from a specification of the specification. As for the point about code being non-normative, I agree however the core specification I don't believe should have any as anything complex that would warrant it such as algorithms should be placed in separate documents.
Thoughts?
Apologies for the late reply. I would like to think it is redundant, however the results of the ntpv4 standardisation effort leave a lot te be desired as an implementer on specifically that point, hence the suggestion. I can see your point though of steering away from this sort of constraints.
If anything I should apologise, after I fix my github notification settings...
The solution to preventing ambiguity over normative and non-normative text is not mandating it via the requirements draft, which is difficult to quantify as the measure has a degree of subjectivity, but that people like yourself review and feedback - and if they aren't addressed by the authors to make it audible on the list to get consensus calls made.
Ok, I'll definitely do that.
This suggestion is in response to some (in my view) issues regarding clarity of what is required by the NTPv4 specification, and what is merely implementation suggestions and hints.