Hi Ian, Examples are useful because they give the IESG something to chew on. If you don't call us when we do "bad stuff" we might never know. Examples can be dangerous because we can rat-hole into the specific rather than the general, but i would like to use your example as data point to get some more information that can possibly be generalised. > 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. Do people believe that the extensibility bit should not have been added? I.e., is it a dumb or unnecessary thing that was forced on the community by the IESG? Maybe it is "harmless" so everyone said yes to get the document published. Maybe the IESG had some "insight" suggesting that it was important to future-proof the protocol even though the community didn't think it important. Maybe it was a really cool idea that everyone missed. I'm not asking in order to have a fight about whether the AD was right or wrong. But I would like to understand more about the impact of this type of "blocking" Discuss. My point here is that sometimes it happens that ADs spot holes in protocols. In those cases, I think we could live with publishing the RFCs and fixing them later, but it is on the whole better to fix the issues at the time they are spotted rather than later. The problem comes that an AD (especially out of expertise) cannot tell between "I think there might be a problem here" and "I know this is a serious bug". I believe that the clue is in the word "Discuss" and I hope that I (at least) am willing to listen when the response is "we thought about it, it's not a big problem." Perhaps people will tell me I am not so good at listening! I know other ADs also strive to that as an ideal, so perhaps we have something of a communications breakdown... Discuss is not meant to mean "and you shall not move unless you do exactly what I say." It should mean "Please help me to be happy about publishing this document because what I really want is you to publish the best possible document as quickly as possible." Thanks, Adrian > > 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