On 27 Oct 2020, at 16:16, Michael Thomas wrote:
Why on earth would I want to be a drama queen? Especially since I had
no dog in either fight?
The fact that you think invoking them makes you a "drama queen" means
that you are part of the problem. And the idea that if you "don't have a
dog in the fight" means that you shouldn't fully participate (including
using the pushback mechanisms we have), you're not understanding what
the IETF is supposed to be about: We have plenary meetings and Last
Calls and the like so that groups can get cross-area and outside
feedback. Failure to call out problems simply because you're not a
primary player is exacerbating the cultural problem you claim to see.
Barry handled the author fine, iirc. It's just that wg as a whole
dismissed the problem even though what I predicted is exactly what
happened. They wrote my concern into the security requirements with
like a one sentence dismissal and everybody ignored it.
And you didn't follow up with the chair or AD when that happened?
Isn't this thread about getting outside clue to the attention of the
working groups more seamlessly? Your quoted process and sympathy is
exactly the wrong way to foster that.
Well, let's be clear here: The original thread was about how people who
are outside of the IETF community can communicate protocol
vulnerabilities. Your original response was "isn't the basic problem is
that working groups don't want to hear criticism or take it seriously?"
and then gave examples of your recent experiences dealing with feedback
not being taken by WGs. But you are a regular IETF participant, insofar
as you're subscribed to the IETF list and are participating (however
much) by directly communicating concerns to WGs. I was addressing your
comments, not the kinds of problems that a complete outsider would run
into.
In OAUTH's case I did talk to Barry. For STIR after seeing what they
did to Crocker at last call it was apparent that it would fall on deaf
ears so why bother?
Because everyone not bothering actually makes the problem worse.
I did bring it up my concern on their mailing list before I read the
archives, but crickets.
At which point you should have gone to the chair. If a mailing list is
misbehaving (which includes ignoring comments), that's a failure on the
part of the chair and needs to be dealt with.
The flip side of this that nobody wants to be seen as an insane
Casandra in case you are actually wrong.
Nobody who says, "I think there may be a serious problem here. This
protocol does X, Y, and Z, and those appear to be serious security
vulnerabilities. Am I off the mark here?" gets seen as an insane
Casandra. On the other hand, if someone comes in saying, "This protocol
is a complete mess because of X, Y, and Z. WTF?", yeah, they might be so
labeled. On the other hand, someone like that strikes me as someone who
doesn't care about such labels.
If you want outside clue but the reality is that they treat you as the
enemy, you're not going to get the desired result. Any fix for this
needs to account for that.
The problem you're identifying is fixed by IETF participants pushing
back on such behavior using the mechanisms we have in place to do so.
On 27 Oct 2020, at 20:14, Michael Thomas wrote:
I said that most of Dave's problems were ignored and that there was a
lot of snarling about it being brought up in last call. Peterson in
particular impugned Crocker for that, as if last call was a bad time
for comments.
It is always the case that late comments, particularly ones that require
substantial changes to address, will always be a bummer and, being human
beings, sometimes cause grumpiness. But our processes are designed to
deal with such things, and if they are being invoked appropriately or
otherwise being ignored, that's a problem.
When I looked at it years later it was like "holy shit, what a mess".
That was well before I saw Crocker's comments.
So the correct moves for an IETF participant in such a situation are to
do one of the following: (1) Bring the concerns up on the list and see
if the WG can address them; (2) If the problems are individual points in
the document that are correctable, file one or more errata; (3) If there
is a serious flaw, start the appeal process for the case where "the
Working Group has made an incorrect technical choice which places the
quality and/or integrity of the Working Group's product(s) in
significant jeopardy." Yes, that process is normally used for
pre-publication, but I see no reason it can't be instantiated for
post-publication. Resolutions could be the IESG chartering new work to
correct the problem or adding a work item to a still existing WG, the
IAB deciding to publish a document describing the problem, etc.
I will point out however that "I would have done this completely
differently" or even "this is an architectural mess" are not valid
reasons to make a change: Internet email is arguably an architectural
mess compared to X.400, but deployment and successful interoperation
tend to be overriding in IETF discussions.
It took me months to get answers of what in hell was going on. [...]
This is what you are up against.
I'm still trying to figure out what you in particular are up against.
My point is that there is a culture that snarls at that feedback after
the fact...
Look, as I said above, we are human beings in the IETF, and people will
sometimes react poorly to feedback. (Again, I'm speaking generally; I
don't know what actually happened in the cases you pointed out.) But
when this happens completely internally to the IETF, it is incumbent
upon participants to pull the levers we've got to correct those
problems, because failure to do so will absolutely develop a culture of
poor handling of feedback, both internally and externally. When a
regular IETF participant complains about outcomes but has never used the
procedures we have for handling problems, that person is part of the
problem.
...and if you truly want constructive feedback you need to address
that.
Who is this "you" you speak of?
And I have no clue what the processes are. Why should I? I only
cursorily pay attention to IETF.
stuff these days.
Sorry Michael. I count 83 messages from you in the past year in the IETF
mail archives. You don't get to claim "drive by" status. You are an IETF
participant. At this point, you should at least know what RFC 2026 is
and have a passing understanding of our processes. I'm certainly bummed
by Rich's comment that the conflict resolution process is not mentioned
in the newcomer's orientation; that seems like a gaping hole to fix and
I'll try to be part of fixing it. But if you're going to participate as
you have been, you should know some of this stuff, or at least be able
to ask about it when need be.
Is that to say that you don't give a shit about somebody who looked at
something with fresh eyes and was
like wtf?
Nonsense. We get feedback like that all the time. Sometimes, that
feedback is good and we take it on. Sometimes that feedback is nonsense
and we try to respond respectfully and ignore it. Sometimes, due to the
grumpiness of the sender or even of the receiver, that feedback can get
inappropriately. It's all of our collective responsibilities to make
sure that is corrected.
It's like Pete Resnick dismissing me because I didn't properly
escalate things.
I'm not dismissing you. I'm saying you haven't made your case. You said
there is this systemic cultural problem, yet you are part of the culture
and haven't used the mechanisms we have in place to deal with the
problems you have described. If you were an outsider, I wouldn't have
pointed you to those procedures if you had a complaint; I would have
simply helped you find the right person to talk and helped you address
the problem. But you're not an outsider. You are an IETF participant.
Take responsibility for changing the things that you can and do your
part.
99.9999999% of people are not encultured in IETF process. If you want
casual people to be able to have a say about "hey, something is wrong
here!" you need to accommodate their lack of clue about process.
Yeah, absolutely, but my point is that this isn't you or the incidents
you identified. You identified internal IETF participants (yourself
included) not being listened to. If that's the case, you should have
known enough to use the processes. The original thread is absolutely
about how to get the comments of external folks into the mix. But that's
not what you've been talking about.
On 27 Oct 2020, at 20:26, Michael Thomas wrote:
PS: i hope that this doesn't turn into a prosecution of whether my
examples are right or wrong because that utterly misses the point.
Totally agreed.
The issue here is that working groups are tribalistic and people who
upset that tribalism are the enemy. until you
deal with that problem, nothing will happen.
Again, the "you" you mention includes you, Michael. You don't get to
push this out as if you are not part of the community. And the way you
individually can address this kind of problem is to actually use the
mechanisms we have in place to do so.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
