Comments on the draft. HTH.
--aaron
----
General
Should the draft address the issue of applications that want to go
directly to a specific transport protocol and bypass TAPS? For example,
this may affect capacity profiles predictions.
4.2. Branching Order-of-Operations
....
usable DNS results on one network may
not necessarily be the same as DNS results on another network due
to
local network entities, supported address families, or enterprise
network configurations.
CDN cache assignment is another reason DNS results may vary by network
interface.
4.5. Completing Establishment
....
an implementation may choose to hold
onto fully established leaf nodes that were not the first to
establish for use in future connections, but this approach is not
recommended since those attempts were slower to connect and may
exhibit less desirable properties.
Seems like there are other good reasons not to encourage holding
duplicate connections open such as consuming valuable server resources.
6.2. Handling Path Changes
Is there a realistic case where, say, a routing change causes a protocol
to stop working. Should TAPS deal with this?
10. Rendezvous and Environment Discovery
....
o Gathering Remote Endpoint Candidates
As in sec 4, I think it may be worth mentioning that DNS resolutions may
vary by interface (e.g., with CDNS). Perhaps there should be a
recommendation to perform DNS lookups separately for each interface to
get the remote IP address._______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
