Howdy, At the mic I was pointing out that there were cases like EDNS0 options that resulted in fairly significant changes to the operations of a protocol, and that these can be combined in ways to produce a number of different combinations. My concern is that creating a general purpose framer for all of these combinations may be difficult or ossifying, as new options continue to be introduced. I can see it as a potential implementation choice, depending on the generality required, but I can also see implementations where allowing the DNS application to manage this results in both simpler and more correct behavior.
Among EDNS0 options to consider here are things like the TCP-specific options ( ends-tcp-keepalive <https://tools.ietf.org/html/rfc7828>), the addition of padding <https://tools.ietf.org/html/rfc7830>, or the use DNS cookies <https://tools.ietf.org/html/rfc7873> in different transports. There are also potential odd cases like CHAIN <https://tools.ietf.org/html/rfc7901> or EXPIRE <https://tools.ietf.org/html/rfc7314>which are intended to be used only in specific relations. I remain pretty convinced that DNS is a good customer for TAPS, but it is my personal impression that more discussion is needed to understand whether this layering helps or hinders that going forward. I'm glad to know that it will be a topic for the interim, and I'll try to attend. Ted
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
