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(_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