Christian Hopps writes: > We certainly did not want to specify whether an implementation > SHOULD forward complete inner packets, out of order, or not, b/c > that is not required for interoperability.
My reading is that current text says you MUST NOT forward complete inner packets until all earlier packes have been received and you are sure you have been able to sort the outer packets to in-order, and you can only do that after the missing packets have dropped out of reorder window. > Implementations could very well decide to offer one or both options. > Our job is to specify the on-the-wire behavior so that > implementations interoperate. I disagree on that. We also want implementations to do sane and smart things, it is not just enough that they interoperate. Also specifying recipient processing is good way to verify that your transmit processing is also correct. I am working also on the IEEE and they always say that they do not specify receivers, they only specify transmitters, as implementing receiver is left as exercise for the reader, and can simply be done by "reversing" what transmitter does. This cause cases where they send two variable length strings in one frame, without delimieters or lenght fields and do not notice this as they only specify transmitter. This is easy to implement on the transmiter end but impossible to implement on the receiver... Or in one case where their channel hopping sequence was selected by calculating the hash of the packet. Very easy to do on the transmitter as he has the packet. Bit harder to do on the receiver end as he would need to be constantly trying all possible channel hopping sequences and trying to see if any of them forms a packet... I have always considered it very good that in the IETF we do try to mandate or at least give instructions for the receiver end too. That makes it much easier to do interoperable implemenations. > You are suggesting that we should add a “MAY” to the same affect > though. That seems like a non-controversial change that could be > made. Yes, I propose changing the MUST NOT to MAY... > Adding a more text pointing out the obvious results of this choice > (i.e., that sending inner packets early can create downstream out of > order delivery, or that waiting for outer packets can add delay and > bursti-ness) would not be my preference. It might be obvious to you, but it might not be obvious to the person doing the actual implementations. I always consider it a good idea to point out pitfalls and cases where implementor should be vary to the implementor and not to assume that implementor actually realizes this. > As a general rule I try (and I’m not alone in this) to avoid adding > unneeded text, b/c the best you can hope for is to not say it wrong. If you add unneeded text and find out later that it was then that was good thing, as it clearly indicated that the text in question was not clear enough. Adding more text that clarifies things is good thing. > That said if you believe the text must also include these 2 points > as well i will add them in order to move things forward. I think it would be worth explaining, as it might also cause the implementor to think which option to choose. I.e., if he is more concerned about the reordering, and do not care about the burstiness or delays he will pick one option, but if he care more about the latency he will pick another option. > Would you be agreeable to just adding the clarifying “MAY” > statement? I think adding explaination about what the effects the two options for MAY have is something that is good thing to add too. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
