Ahh, sorry, no … I ALWAYS try to carefully check everything and THEN a thought appears immediately after pressing the “send” button. About aborting vs. closing:
>> --- >> Abort without delivering... >> >> Abortis currently specified for SCTP and TCP. If one assumes the bound >> semantics for UDP(Lite) this also seems also the correct primitive for >> UDP(Lite. >> >> Should this ID specify a connect primitive also for bound use of UDP(Lite)? > > Okay, I think you found an error here: > Both “connect" and “close" primitives exist in > draft-ietf-taps-transports-usage-udp, and were taken over into step 2 of > draft-ietf-taps-transports-usage. Step 3, which is where the transport > features in minset come from, misses UDP(-Lite) under “close” ! > As I was writing the more elaborate description of “close” in step 3, "Close > after reliably delivering all remaining data, causing an event informing the > application on the other side”, I felt I really couldn't place UDP(-Lite) > there, I think this is how it was dropped. UDP(-Lite) would have survived if > this would have been called “ABORT”, and here’s the mistake: semantically, as > you identify here, UDP(-Lite)’s “close” is really equivalent to “abort”, not > “close”. I can fix this in the next update of the -usage draft, and adjust > the -minset draft accordingly. What I just wrote here about being semantically equivalent to abort is wrong. The full description of abort, in step 3 of the usage draft, is: "Abort without delivering remaining data, causing an event informing the application on the other side" UDP(-Lite) doesn’t inform the application on the other side. I guess we should give it a new name (“Abort without delivering remaining data, without causing an event informing the application on the other side”) and then process it in -minset like we processed all the others. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
