Paul Hoffman wrote: > > At 6:57 PM +0100 1/26/10, Martin Rex wrote: > >The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6! > > ...as are about half of all MUSTs and SHOULDs in modern IETF standards. what do you want to say with this? That implementors should ignore at least half of the MUSTs and SHOULDs in IETF documents, because they don't make any sense, create unnecessary interop problems or are otherwise harmful -- and should not be in the document in the first place? That may apply to IETF documents where you were involved in the process, but it did not apply to documents where I was involved ... so far. The engineer in me is unable to just close his eyes on obvious problems, in particular when there is an easy fix, I'm sorry. > > >Did anyone of you review the new sections in the -03 draft? > > Yes. The authors should be interested in the inconsistencies you likely have encountered while reviewing the -03 draft. Some aspects are likely more apparent to implementors (one of the reasons for the IETF "we believe in running code" attitude) -- and to those who are sufficiently familar with code implementing this part of TLS to think in terms of actual lines of code, code complexity and testing effort while reviewing the document. > > >I do not think that rushing the document out of the door as-is > >would be a good idea. This would set new lows for the level > >of IETF Proposed Standard. > > This indicates that you need to read more standards-track RFCs, then. What is your suggestion to improve the situation? Reading I-Ds during IETF Last Call and providing feedback to the authors and/or working group might help. But that requires that a document is in a resonable shape when it is being Last Called. draft-ietf-tls-renegotiation-03 is the first version of the document that is in a shape close to the expectations of the IETF for documents targeting Proposed Standard. There is considerable a considerable of changes in -03 that wasn't in any prior version of the document, and there are changes to the semantics (two entirely new MUST NOTs and two unexplained NOT RECOMMEDEDs) that are _not_ aligned with the WG consensus preceding the -03 document and they are in conflict with rfc-2119. Any discussion (let alone consensus) on the changes in the -03 document was preempted by the IESG approving the document in less than two days after publication during the holiday season. I'm not asking for a new change, I'm asking for a _revert_ of a new change that creates several unnecessary problems. And I'm asking for an editorial review of the -03 draft, since some would seriously benefit from editorial corrections. The IETF used to be a standardization body with an open and fair process where technical merit, running code, technical objections and rough consensus of those who cared was more important than any count of votes. I don't want to hold up the document. I did _not_ complain about the premature IETF Last Call because I was still hoping the document quality issues could be resolved entirly during WG discussion (there were ~5 complaints). I _urged_ Pasi to make his consensus call on SCSV semantics on Dec 16th, when there was still plenty of time considering the (lack of) document quality at that point. In order to help on fixing the problems -03, I even provided an updated document as suggestion for all the issues that should be fixed before publication. After all, the target audience of this document is supposed to be much larger (within a very short time frame) than most other documents published by the IETF. Therefore the technical quality appears to be significant, in spite of the importance of getting the solution implemented. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf