SM wrote:
Hi Carsten,
At 11:46 09-08-2011, Carsten Bormann wrote:
For another perspective on this, see section 2.7 "The fallacy of
perfection" in "Garrulity and Fluff".
(http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf)
That's an interesting document. From Section 2.1:
Yes, it is a interesting document.
.... In simple terms, that
protocol that has been designed to do almost everything won't gain
traction if the input from operators is not taken into account.
+1 and this, in my opinion, is the blessing and curse of the IETF and
when coupled with the outdated Rough Consensus decision making
guideline, it can have had a negative impact in the final outcome.
I have been part of several open technical standard organizations
where the philosophical difference of the mixed discipline
environment, i.e. Administrators vs Developers was the source of doom,
especially when the art of compromising is lacking or unachievable.
My view, it all begins with the main source. It is very important the
editor(s) recognize input is coming from all sides. Once they shun
one group over another and use Rough Consensus (RC) as the measuring
stick to shun others, its over. Everyone loses.
RC is ok when everyone in the group (team) have a similar discipline
or mindset. But when there extreme mindsets, it simply doesn't work
for the benefit of the main WG or protocol goal. This is like
prematurely inviting a technical sales team, documentation team or
help desk to a project R&D effort. They might fit better during a
early functional requirement stage or Product R&D effort, but when
conflicts mindset are smack in the middle of a protocol design, that
spells problems.
Of course, All input is input so generally, at the end of the day,
this is more about a management problem - a.k.a IETF WG Chairs.
Ideally, the editors should be very keen to these differences
Anyway, today, I don't think Rough Consensus is a good decision
making, issues settling tool that can resolve problems by blowing away
a good size minority out the door. That causes problems. When there
is disperse group, I believe a super majority is a fundamental and
statistically correct requirement that have a maximum beneficial
outcome. This is akin to adding features to a product; when there is
no clear answer - you make it optional. Throwing it away will invite
support issues. :)
I said more than I wanted to, but its just my opinion.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf