On 10/28/20 9:42 AM, Pete Resnick wrote:
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.
You realize that this is a thread about outsiders contributing
vulnerability clue without necessarily having any IETF knowledge here,
right? Your hectoring is particularly ironic.
I don't go to meetings anymore. I only occasionally look at things
rfc/groups/etc that interest me. I was never a creature of process
archana even when I did. So I'm not a terrible proxy for somebody who is
completely naive.
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?
I just said that Barry Lieba -- wg chair -- handled the hysterical
author well. Well, as well as could be expected.
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.
I'm mostly an outsider these days. So I'm bringing the perspective of
somebody who knows some of the process that I wouldn't need the kind of
guidance being hatched here, but have been on the receiving end of where
it goes once routed. I imagine that people who also got the same
treatment are not going to bitch about it on the ietf list because...
they don't even know about it, and don't care enough about the meta problem.
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.
I could have done that, but after reading the archives made the
calculation that it was a waste of time. Frankly the security flaw I
found is probably the least of its worries. It is so underspecified that
apparently I can use gopher: or ftp: method in the URI that fetches
certs. That is the level of carelessness and underspecification we're
talking about. So I did what any sane person would at that point:
"You're on your own, son".
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.
Uh, living proof right here. I'm willing to believe that it's uncommon
though because that particular author was particularly egregious. But
the entire thing turned into a "it's not a problem because it's not
fixable" wtf twilight zone.
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.
What exactly is the alternative? I mean that is what last call is for,
right? If I don't have a lot of involvement with something but am
interested in the outcome, that is the time that I'm going to read it
over and see if there are problems. In that particular case, there were
so many that the comments it was pretty much a novel. That doesn't bode
well especially given who gave the feedback. I scanned it over afterward
and eyeballing it maybe 10% of the comments were incorporated. A lot of
them were stylistic, but a lot of the substantive ones didn't lead to
any changes in the document.
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.
On the list I was only interested in a couple of things: a potential
security flaw that I found, and whether STIR covered the
sip:mike@xxxxxxxx case. The first got ignored, the second got discussed
quite a bit but it's still not entirely clear whether it does or doesn't
which is its own kind of flaw. As I said, I just casually participate in
things that interest me and then go back into hibernation. So I'm sort
of a maybe more process clueful type of person this thread is about. I'm
definitely not interested working some long process to prove a point.
Too much work, too little gain.
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.
I made no architectural arguments, though I do have opinions not
expressed. Just the quality of the document and potential security problems.
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.
Look at the years before that. It's been very sporadic since I left
Cisco 12 years ago.
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. 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.
Hence why I've responded. yes, it should be we but i don't feel entirely
we these days. IETF does allow for this sort of meta state, which is
maybe one of its charms.
Mike
pr
