And that should, of course, have read "Hi Lloyd" Sorry about that, Lloyd. The rest of the message still stands. Adrian > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Adrian > Farrel > Sent: 11 April 2013 22:18 > To: l.wood@xxxxxxxxxxxx > Cc: ietf@xxxxxxxx > Subject: RE: Purpose of IESG Review > > 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