This looks like good progress. A few very specific comments below:
---
I see phrase:
" Because QoS is out of scope of TAPS, this document assumes a "best
effort" service model [RFC5290], [RFC7305]. "
I'm not sure we need to state this. Although I agree that TAPS will not
propose new QoS techniques, the service provided by TAPS is, I think,
also not confinded to "best effort".
---
I am not sure that IP options from UDP are entirely automatbale.
Per-packet IP options could be related to application use of the
network, and I think this would require some form of API interaction.
---
I see LE service as something interesting, yet this does not exactly fit
the rest of the draft. The cited reference is to a DiffServ PHB, and the
LEDBAT referenced is a transport protocol mechanism, not a protocol. I'm
not sure this inclusion is justified in the current tetx.
---
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)?
---
What should be said about SCTP usage of IP OPTIONS? I would have
expected if the endpoint network layer set these, they would also work
for SCTP?
---
Finally,
I think I can agree the argument that UDP(Lite) message handling is
different to SCTP.
---
Gorry
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
