+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(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Paul Hoffman [paul(_dot_)hoffman(_at_)vpnc(_dot_)org]
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(_at_)isi(_dot_)edu> 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