DNS/WhenToClarifyについて、ここに記述してください。
https://www.ietf.org/mail-archive/web/dnsop/current/msg15963.html
My response this is intended to apply to "refuse-any" (i.e.,
https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-01). Based on
my experience in writing clarifications RFCs:
0. Clarification means change. There's no sugar coating it, clarification
disrupts backwards compatibility. So set a high bar before adopting a
clarification.
1. Insufficient original text is not sufficient cause to change (clarify)
the specification. ("Insufficient" is a subjective term.)
2. Reason to change (clarify) the original specification is when
demonstrable barriers to interoperability exist (that cannot be dismissed
as buggy code). I.e., if by design, due to diverging, plausible
interpretations of the specifications, two or more implementations cannot
interoperate, there's grounds for a clarification.
3. Running code trumps written documents.
If interoperability is achieved with insufficient original text, the text
is evidently sufficient.