7 ms·

I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.

by mjg59 1y ago

timschmidt 1y ago
Having served on boards, rejections on procedural grounds which fail to address engineering concerns which have been raised stink of a cop-out.
- mjg59 1y ago
  Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
  - timschmidt 1y ago
    > Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.
    - mjg59 1y ago
      There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.
      - timschmidt 1y ago
        > and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've read and linked to.
        mjg59 1y ago
        As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was raised to the IESG, who are not the point of contact for engineering issues, the response is focused on that. There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.
        timschmidt 1y ago
        > There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise I wouldn't be aware of these dangerous developments. Excuses of any kind ring hollow in the presence of historical context around NSA and encryption standardization, and the engineering realities.
        mjg59 1y ago
        Hey, look, you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time, he just disagreed with the conclusions reached. He made a complaint to the ADs, who observed that he was using an email address with an autoresponder that asserted people may have to pay him $250 for him to read their email, and they (entirely justifiably) decided not to do that. Dan raised the issue to the next level up, who concluded that the ADs had behaved entirely reasonably in this respect and didn't comment on the engineering issues because it's not their job to in this context. It's not a board's job to handle every engineering complaint themselves, simply because they are rarely the best suited people to handle engineering complaints. When something is raised to them it's a matter of determining whether the people whose job it is to make those decisions did so appropriately, and to facilitate review if necessary. In this case the entire procedural issue is clear - Dan didn't raise a complaint in the appropriate manner, there's still time for him to do so, there's no problem, and all the other complaints he made about the behaviour of the ADs were invalid.

I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.

by mjg59 1y ago

I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.

timschmidt 1y ago

Having served on boards, rejections on procedural grounds which fail to address engineering concerns which have been raised stink of a cop-out.

mjg59 1y ago
Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
- timschmidt 1y ago
  > Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.
  - mjg59 1y ago
    There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.
    - timschmidt 1y ago
      > and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've read and linked to.
      - mjg59 1y ago
        As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was raised to the IESG, who are not the point of contact for engineering issues, the response is focused on that. There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.
        timschmidt 1y ago
        > There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise I wouldn't be aware of these dangerous developments. Excuses of any kind ring hollow in the presence of historical context around NSA and encryption standardization, and the engineering realities.
        mjg59 1y ago
        Hey, look, you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time, he just disagreed with the conclusions reached. He made a complaint to the ADs, who observed that he was using an email address with an autoresponder that asserted people may have to pay him $250 for him to read their email, and they (entirely justifiably) decided not to do that. Dan raised the issue to the next level up, who concluded that the ADs had behaved entirely reasonably in this respect and didn't comment on the engineering issues because it's not their job to in this context. It's not a board's job to handle every engineering complaint themselves, simply because they are rarely the best suited people to handle engineering complaints. When something is raised to them it's a matter of determining whether the people whose job it is to make those decisions did so appropriately, and to facilitate review if necessary. In this case the entire procedural issue is clear - Dan didn't raise a complaint in the appropriate manner, there's still time for him to do so, there's no problem, and all the other complaints he made about the behaviour of the ADs were invalid.