Reply to below message The subject SHOULD be: Evaluating Review Process Performance I prefer the Subject is: Evaluating WG input, the WG review process, and the WG output, NOT IESG review. ------------------------------------------------------------------------------------------------ Hi Joe, My comments mostly is on your message, but I comment also on I-Ds or RFCs related to IETF (including joky RFCs). I don't think it is write to evaluate the review of an IESG as long as when we created the I-D and adopted it into IETF SYSTEM, it is already agreeing on the methods of process that I-D is going through. So the problem is to evaluate three things not one: 1) the input, 2) the process review, 3) the output. We may make different input methods that go to another body than IESG, but if you decided to make I-D under IETF current procedure, it will have to go to IESG. I think the IESG are doing an excellent job, but it is best them to evaluate their performance not the community. Or it is better to find a body that evaluates the IESG performance not on this list. I consider your input on the list as a complain about the process, so I ask you to notice that your input has an error that needs evaluation befor going to process evaluation. You may evaluate output, but I remind you to evaluate input of WGs and inputs of individuals. I think the BIG problem of delay in I-Ds or RFC, is the cause of the WG not the IESG, if you do an excellent WG processes you will get quick results at IESG. AB +++++++++++++ Hi, all, As an author who has had (and has) multiple documents in IESG review, I've noticed an increasing trend of this step to go beyond (IMO) its documented and original intent (BCP 9, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their "IESG Review" (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe