31–40 of 170 posts
Earlier quoted context omitted.
Postel's law is considered more and more harmful as the industry evolved.
I think it is okay to accept liberally as long as you combine it with warnings for a while to give offenders a chance to fix it.
I'm not an IETF process expert. Would this be worth filing errata against the original RFC in addition to their new proposed update? Also, what's the right mental framework behind deciding when to release a patch RFC vs obsoleting the old standard for a comprehensive update?
Otherwise I might go to consult my favorite RFC and not even know its been superseded. And if it has been superseded with a brand new doc, now I have to start from scratch again instead of reading the diff or patch notes to figure out what needs updating.
And if we must supersede, I humbly request a warning be put at the top, linking the new standard.
After the release got reverted, it took an 1hr28min for the deployment to propagate. You'd think that would be a very long time for CloudFlare infrastructure.
Earlier quoted context omitted.
I think it is okay to accept liberally as long as you combine it with warnings for a while to give offenders a chance to fix it.
"Warnings" are like the most difficult thing to 'send' though. If an app or service doesn't outright fail, warnings can be ignored. Even if not ignored... how do you properly inform? A compiler can spit out warnings to your terminal, sure. Test-runners can log warnings. An RPC service? There's no standard I'm aware of. And DNS! Probably even worse. "Yeah, your RRs are out of order but I sorted them for you." where wo…
Through the appropriate channels; in-band and out-of-band.
A great example of Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." combined with failure to follow Postel's Law: "Be conservative in what you send, be liberal in what you accept."
Postel's law is considered more and more harmful as the industry evolved.
What's reasonable is: "Set reserved fields to 0 when writing and ignore them when reading." (I heard that was the original example). Or "Ignore unknown JSON keys" as a modern equivalent.
What's harmful is: Accept an ill defined superset of the valid syntax and interpret it in undocumented ways.
After the release got reverted, it took an 1hr28min for the deployment to propagate. You'd think that would be a very long time for CloudFlare infrastructure.
> However, we did not have any tests asserting the behavior remains consistent due to the ambiguous language in the RFC. Maybe I'm being overly-cynical but I have a hard time believing that they deliberately omitted a test specifically because they reviewed the RFC and found the ambiguous language. I would've expected to see some dialog with IETF beforehand if that were the case. Or some review of the behavior of com…
My reading of that statement is their test, assuming they had one, looked something like this: rrs = resolver.resolve('www.example.test') assert Record("cname1.example.test", type="CNAME") in rrs assert Record("192.168.0.1", type="A") in rrs Which wouldn't have caught the ordering problem.
It’s always DNS.
After the release got reverted, it took an 1hr28min for the deployment to propagate. You'd think that would be a very long time for CloudFlare infrastructure.
Any change to a global service like that, even a rollback (or data deployment or config change), should be released to a subset of the fleet first, monitored, and then rolled out progressively.