On 15-Jul-23 18:08, Michael Thomas wrote:
On 7/14/23 2:39 PM, Brian E Carpenter wrote:
Michael,
This is why I'm so concerned about why this happened and how to
prevent something like this happening in the future. That's
especially true when it involves security risks at a very large scale.
We have public IETF last calls, we have organized review teams, we
have a published IESG agenda and announced IESG telechats, and we have
substantive IESG comments and ballot positions in the datatracker. All
of these are intended so that any community member can intervene right
up to the point of IESG approval. Then we have a window of two months
during which any community member can appeal an IESG decision.
People who are not on ietf-announce@xxxxxxxx and last-call@xxxxxxxx
have chosen not to participate in these parts of the IETF process.
I really don't see what else we can do to detect and correct IESG
errors. This long after the event, there is no process recourse, but a
new BCP is always an option. Have you written a draft?
Brian. I am reminded about the DNS race condition problem. It made it
past last call probably 30 years ago. What you seem to be saying is that
those of us who didn't pay attention back at last call should shut up
because we had our time to diagnose the problem at that time.
No, I'm saying that after the RFC is out, the only way forward is a
new corrective RFC via the complete IETF process. That is not easy or
straightforward, but it needs to be done.
I'm not just saying it. None of these are security related, but I've
helped with RFC3879, RFC4048, RFC5954, RFC6343, RFC6563, RFC7526,
and draft-ietf-6man-rfc6874bis, all of which are corrective. The
IETF doesn't do enough of such work.
As a data point, the average delay between the original RFC and the
corrective RFC in the first 6 cases above was 9.7 years.
Almost
nobody knows what the proper way is to push the panic button.
Well, it's the "Reply" button when you receive an IETF Last Call
message. While that isn't obvious to an outsider, active participants
should know it.
I agree we probably have a documentation gap - a new item on the page
at https://www.ietf.org/standards/process/ might help, for example.
This is a
highly IETF-centric view of the world and sends the message that IETF is
insular and is not interested in outside review. Is that what you want?
That outside review is discouraged? That moderators should squash that?
That has been the net effect of this thread that outside review is not
appreciated and that the mods are acting as that cat's paw.
I'm not sure what an "outside" review is for an organisation with open
membership. I don't think that's the issue here, really. The issue is
that this list is simply the wrong audience. If the security lists won't
listen, that is definitely a problem but one that the Security ADs and the
IETF Chair are responsible for.
Yes, I am not on the those lists. What of it? Are you trying to say that
nothing should change on the ground after that?
No, I'm saying that those are the lists where any person can track the final
parts of IETF decision making, and if a person doesn't do that, they miss
the opportunity to intervene before a decision is final.
Or that it is
irrelevant? Or that not knowing the precise process invalidates the
finding?
Not at all. But it means missing all opportunities to stop a
document, and the result is that it becomes a lot harder to resolve
the issue, because a whole new document is needed. That's a lot
more work, apart from anything else.
(Sad but true: the IETF is a document factory, nothing else.)
Trying to shame me serves no purpose other than to shame
somebody who discovers a problem long after the fact.
I really don't think anyone is trying to do that. I'm sorry
if any of my words made it seem like that.
Paul Vixie at
least had a lot of cred with DNS. Me, I'm a nobody. So is it really
credentialism that is important? Is that what IETF wants? Do you want us
to shut up because we have no creds? That our jobs (or lack thereof) is
not 100% focused on IETF?
Actually the worst thing that can happen to the the IETF is if people's
jobs are 100% focused on the IETF. I'm pretty sure that Paul's isn't, and
never has been.
Regards
Brian
Mike
