Paul Hoffman wrote: > > [email protected] (Martin Rex) wrote: > > > > Paul Hoffman wrote: > >> > >> This is not an erratum, it is a proposal to add operational guidance > >> for how TLS servers should act when an associated TLSA record of a > >> certain type would be used. The guidance is correct, but it is not > >> an erratum. > > > > Erratums _include_ omissions. > > I understand why you might feel that way, given how often your positions > are not supported in WGs and yet you repeat them nearly endlessly. > However, that's not what the RFC Errata system is designed for.
You're significantly mistaken. The IETF has an underlying principle of "we reject Kings, Presidents and voting. We believe in rough consensus and running code". The same is illustrated by what I previously quoted from rfc2026. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, The IETF values feedback from implementors, and most situation where Implementors return the feedback "this is not sufficiently clear", deserves a clarification to be added. When it comes to implementation experience, the feedback from implementors is significantly more relevant that the personal taste in purely theoretical review (and decision / rough consensus based on it) and more relevant than personal taste of assigned document editors. And filing clarifications to Proposed Standards, that are going to result from implementation experience, through the RFC errata process is perfectly valid, because that is what rfc2026 implies to apply for Proposed Standards. Really, the IETF needs to be much more appreciative of implementors feedback, or we will see less of such feedback in the future! -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
