I appreciate the clear statement of transport requirements in S3.4.
You state that deduplication is a requirement of the transport, but then in S7
you state that some transports don't actually meet the requirement, and what to
do in that case. So it really isn't a requirement, is it? Just a nice to have!
It would be good to state that in 3.4.
Is it really necessary for the transport to handle reordering? IIUC this
protocol consists of up to 4 atomic messages that fit in a datagram, and each
one is input to the next. How could there be reordered messages in this
context? (Similarly, I fail to see how a transport could support ordering but
not deduplication -- perhaps I'm not imaginative enough).
https://mailarchive.ietf.org/arch/msg/lake/GaGzmZ6djvxSXT8IQkxM1y3g6lc/
COMMENT:
Thanks to Michael Scharf for the TSVART review.
I appreciate the clear statement of transport requirements in S3.4.
You state that deduplication is a requirement of the transport, but then in S7 you state that some transports don't actually meet the requirement, and what to do in that case. So it really isn't a requirement, is it? Just a nice to have! It would be good to state that in 3.4.
Is it really necessary for the transport to handle reordering? IIUC this protocol consists of up to 4 atomic messages that fit in a datagram, and each one is input to the next. How could there be reordered messages in this context? (Similarly, I fail to see how a transport could support ordering but not deduplication -- perhaps I'm not imaginative enough).