Re: [tcpm] RFC793bis draft 14 Reserved Bits

I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to.

Fair enough.

In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use.  Must be zero.").

I agree. However, future features assigning Rsrvd could extend the Control Bits with SHOULD requirements. As ECN shows with SHLD-8 "A TCP SHOULD implement ECN as described in RFC 3168", the usage is recommended, but not required. If someone opts to not include RFC 3168, it is not stated how this TCP must handle the unused bits. I think that an explicit statement of how to handle these cases will be beneficial, i.e., as a MUST within Control Bits of Section 3.1:
"A TCP that does not implement a Control Bits optional feature MUST handle it as a Rsrvd Bit."

Best,
Mike

On 4. Dec 2019, at 16:12, Wesley Eddy <wes@mti-systems.com<mailto:wes@mti-systems.com>> wrote:

On 12/3/2019 12:18 PM, Mike Kosek wrote:

I would second the proposal to be more explicit. If we would add a MUST of unaltered traversal in this specific case, I am wondering if this should be addressed in other fields as well. Obviously there are limitations for certain option types, or src/dst port, but Flags and Window Size seem like perfect fits. Flags would also be the subsequent step of Rodney's and Joe's proposal, as bits would not be covered any longer if they are assigned.

In the case of reserved bits, I believe the reason we're trying to be so clear is that we want any new feature that might use them to work.  At least, in the past when this came up, that was why the current 793bis text on the reserved bits differs a little from the original 793 text (which is just "Reserved for future use.  Must be zero.").

I think it would be a mistake and fruitless to try to say for the other individual fields which ones MUST be unaltered by the network.  Generally, this is the expectation for the entire segment, even though that expectation doesn't typically hold anymore (due to NAT, etc).  I wouldn't say much more than that, because it's inviting misunderstanding that it's okay to twiddle with any bits and violate laying whenever the doc doesn't explicitly indicate not to.

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm