On Sat, Sep 5, 2015 at 11:50 AM, Georgi Guninski <guninski@guninski.com> wrote: ...
If you feel like debugging RFC, start from:
RFC: 2119
https://tools.ietf.org/html/rfc2119#section-5 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional.
This includes many backdoors per lack of formalism.
IMHO RFC must use only MUST or "MUST NOT" to make the ``formal model'' soundly defined (recursively RFC compliant).
While I sympathize with your point of view, and while I would welcome a full equivalence of implementations, exclusivity of mandatory requirements is neither a principle governing today's standardization works, nor, sure enough, a principle that guided the standardization of protocols back in the 1990s. The key words defined in RFC 2119 reflect one one or any combinations of the following: * A robustness principle, codified in the Postel's Law; * Economic interests at stake; * Understanding of the subject matter. Today our community has finally reconsidered the principle that, asking designers to "[b]e conservative in what [they] send, [but] be liberal in what [they] accept", promised robustness on the internet. But the incentives are still the same; interoperability and security are always in tension. It is worth to note that, yesterday as today, we need a better understanding of the subject matter. It should have been obvious that a validation of group parameters has security implications. And, just like any and all security relevant requirements, it should have been made a mandatory check. I second Peter's recommendation; consider filing an erratum. Cheers, -- Alfonso