On 04/11/2014 04:43 PM, Edward Lewis wrote: > 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.
It is, I mean I want this document to published *in the end*, but we are not there yet. > 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. Thus not *as is*. > 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 > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
