+1 to Joe's comment. Example: the existence of the extensibility bit in multipath tcp, which i understand came out of a review by the iesg member responsible for security. In that context, that would be outside the scope of any security review, and the comments weren't raised in a personal capacity years earlier on the relevant mailing list. Sure, getting past iesg only cost multipath tcp a bit. But iesg members exceeding their bounds as reviewers and leaving a personal mark seems commonplace. iesg members are there for expertise in their area and to provide that expertise in focused reviews, not to block until a protocol is redesigned to suit their personal tastes. (That transport expertise is lacking on iesg last I looked and everyone believes they're an expert in transport - 'hey, why can't we just turn off udp checksums for sctp over udp? It's faster!' - another iesg redesign attempt overriding considered expertise of a workgroup - isn't helping here.) There are two examples I know of, off the top of my head, telated to transport because that's my area of interest. Can others provide further examples? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: ietf-bounces@xxxxxxxx [ietf-bounces@xxxxxxxx] On Behalf Of Paul Hoffman [paul.hoffman@xxxxxxxx] Sent: 11 April 2013 19:55 To: Joe Touch Cc: IETF discussion list Subject: Re: Purpose of IESG Review On Apr 11, 2013, at 10:54 AM, Joe Touch <touch@xxxxxxx> wrote: > 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? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. --Paul Hoffman