Paul Hoffman wrote: > All of what you say about the IETF needing more input from implementers > is true. And it is also irrelevant to the discussion of trying to jam > that input into the errata for an RFC.
I would recommend that you actually take a look at the **published** guidelines for errata: http://www.rfc-editor.org/status_type_desc.html and the IESG rules for evaulating submitted errata: http://www.ietf.org/iesg/statement/errata-processing.html an in particular item 4., 5. and 6. on that list, and why the errata process knows about a status "held for document update". > > You don't seem inclined to write down your implementation experience I am not a _DANE_ implementor. However, I occasionally implement specifications an can easily understand Viktors confusion. As I said, this kind of confusion was easily predictable for someone who is in general used to do implementation work: http://www.ietf.org/mail-archive/web/dane/current/msg04252.html > > in operational RFCs, but it sounds like Viktor is. Do you seriously want to suggest such a heavyweight process as writing and publishing an I-D in order to get one single clarifying sentence added into an insufficiently clear "Proposed Standard" RFC? The pragmatic approach is to submitted as errata to the RFC early on, and expect the list of erratas ("held for document update") to grow non-marginally with implementation experience. There is one problem with the current errata processing: it's impossible for the submitter himself to edit the errata after submission. This should be considered a defect of the current User Interface. Due to this defect, it is preferable for the submitter to consult/discuss with document authors or the responsible WG. Not for keeping them from submitting the errata, but for trying to ensure that the errata will be useful to others as well, not just the original submitter. -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
