I’m a little confused by this: > I support publication of this document, but I agree that some things > should be improved before its ready to do so. …
Perhaps this is more of a pet peeve than a to-the-point comment. I don’t see how one can be in support of publishing a document and then suggest changes. In the case of this document, I think it needs a lot of changes (already suggested by many), I think publishing it as is would not be very constructive. Looking at the comments, I keep thinking of “what is the best way to specify a protocol.” This comes up here in the discussion about whether a CDS and CDNSKEY, if both are present, MUST or not MUST be the same. If you think my concern is academic, I’ll refer to the flap over the requirement that a set of data be signed with all algorithms in the DS and DNSKEY set being interpreted as “the validator must see all” even if the validator had a way to build a chain of trust. The basics of protocol specification include: A statement about the set of messages that are to be exchanged. When causes a particular statement to be sent. The reaction to the receipt of a particular statement. I don’t think this version of the document does a good job of that - and my previous comment suggested some fixes. Whether or not the particulars of what I wrote are adopted, I encourage structuring the document according to the three lines above. One reason software is so badly implemented is that the specifications are poorly written. "One reason" - for sure. If you ask me (and you didn’t) it is the responsibility of the IETF to generate quality documents and effort should be extended to make sure what is produced is clear and every requirement testable. When it comes to saying there are statements A and B and that the two are supposed to be equivalent - require that. Require (MUST) the sender to make the two be equivalent. Then write rules for the receiver to deal with “what happens when they are not equivalent.” The latter is done to make the protocol exchange more robust. “Be conservative in what you send, be liberal in what you accept” is advice for implementers, not necessarily protocol designers. The role of the latter is to restrict communications into a form that makes sense. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
