I have noticed a number of rhetorical moves here that are deprecated in IETF
circles
1) Recourse to the IESG
Unless you are on the IESG you should not claim to speak for it. It is
ridiculous to see people who have never been on the IESG, have no similar
experience and have not even architected a design themselves start to predict
what the IESG will do.
In particular the assumption that the IESG is there to stop people
making fools of themselves or stop bad protocols is seriously misguided. It is
certainly not the job of the IESG to predict the prospects of success for a
protocol, they may think it is but the success of previous IESGs in this area
who have attempted to do so is the reason we now have term limits.
The challenge this group faces is not getting it through the IESG, it
is getting through the comments from the security cabal in last call.
If people want to find out how the IESG is going to respond to a
proposal they should talk to Russ. Otherwise please make sure you prefix your
statements 'In my opinion'.
2) Recourse to ignorance
It is one thing to ask for clarification of an argument, quite another
to state that you do not understand any of the points being made by anyone and
that therefore the group should do it your way.
This is something that you can get away with if you are Vint Cerf,
David Clark or Tim Berners-Lee. Otherwise it just makes you look stupid.
If you don't understand a point then ask for clarification. If an
individual's contributions are consistently inexplicable then ignore them. If
the statements are meaningless everyone else will. If they have substance then
someone with more patience will work out what the underlying point might be.
If you disagree with claims of fact then say so. Do not try to
introduce a dispute over a claim of fact by claiming that the other party was
unclear when they were not.
3) Recourse to volume
The volume of posts to DKIM is disproportionate to the content. I am
trying to limit the number of posts that I make.
I think we should consider an interim meeting to discuss design of the
policy system before San Diego.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html