4 ms·

Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger

Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or should still be changed to a "MUST") to ensure a forward upgrade path for larger MTU in future. Otherwise, the network is going to be limited by the lowest common denominator, namely those clients which do not implement any path MTU discovery because it's not a MUST, and only support an MTU of at least 1280 (but no more).

throwaway2048 11y ago
You have to realize that RFCs are not a cudgel to bludgeon people into acting how you would like them to, that never ever works out in reality (at one point IPSEC was a mandatory MUST for ipv6 deployments) because people are free to just ignore them if it makes their life too difficult, and trust me they can and will, no matter what any standard says. RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored. Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it. Rough consensus and running code.
- jorangreef 11y ago
  I doubt that "how things actually work on the internet" is "generally" reflected by RFCs. The history of the internet is people trying to work around and fix RFCs actually ("at least with the popular ones"). If you're going to say "SHOULD" you may as well leave it out because people won't follow it.
  - throwaway2048 11y ago
    You are still taking a way too strongly legalistic view of things, standards are not laws (usually). Its not a "everybody conforms to the spec 100% or its worthless" situation in the vast majority of cases. SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
    - jorangreef 11y ago
      Frankly, the original concern is that fixed packet sizes relative to increasing capabilities are not a good idea for future hardware and software performance (think silly window syndrome or allocating a million 1-byte buffers). It's a technical problem that needs a technical solution (preferably through clearer language describing the issue or else we need to rethink things). I guess most people are simply not writing protocols that will be influenced by these decisions, so they fail to see the impact. Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.
      - throwaway2048 11y ago
        the implied goal of changing a SHOULD to a MUST is to force people to comply, im simply trying to communicate that its really not that simple.

throwaway2048 11y ago

You have to realize that RFCs are not a cudgel to bludgeon people into acting how you would like them to, that never ever works out in reality (at one point IPSEC was a mandatory MUST for ipv6 deployments) because people are free to just ignore them if it makes their life too difficult, and trust me they can and will, no matter what any standard says. RFCs should, and at least with the popular ones, generally do, reflect the status of how things actually work on the internet, not how we might wish they did. If your standards ignore reality, they in turn will be ignored. Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block pmtud, it does not matter if some word in a text document changes somewhere, this will continue to be a reality, so you better be aware of it and be able to cope with it. Rough consensus and running code.

jorangreef 11y ago
I doubt that "how things actually work on the internet" is "generally" reflected by RFCs. The history of the internet is people trying to work around and fix RFCs actually ("at least with the popular ones"). If you're going to say "SHOULD" you may as well leave it out because people won't follow it.
- throwaway2048 11y ago
  You are still taking a way too strongly legalistic view of things, standards are not laws (usually). Its not a "everybody conforms to the spec 100% or its worthless" situation in the vast majority of cases. SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee it will be supported, but when it is supported it is helpful and useful.
  - jorangreef 11y ago
    Frankly, the original concern is that fixed packet sizes relative to increasing capabilities are not a good idea for future hardware and software performance (think silly window syndrome or allocating a million 1-byte buffers). It's a technical problem that needs a technical solution (preferably through clearer language describing the issue or else we need to rethink things). I guess most people are simply not writing protocols that will be influenced by these decisions, so they fail to see the impact. Furthermore, no one said this was about "cudgels" and "bludgeons" or being "too strongly legalistic" or writing "laws". Those are your words, not mine.
    - throwaway2048 11y ago
      the implied goal of changing a SHOULD to a MUST is to force people to comply, im simply trying to communicate that its really not that simple.