On 27/04/2017 08:40, Petr Špaček wrote:
> Other people already commented on semantics so I will focus on message > format: > > My attempts to find reasoning for the new TLV format in archives did not > yield an elaborate explanation. Assuming I did not miss anything, it > seems to me that the current TLV format (placed outside of standard DNS > RR) is going to require brand new code and logic and makes imlementation > harder than necessary. > > Every DNS server and resolver already has own code to parse DNS RRs do > various operations with them but this could cannot be reused for the > current TLV format. > > It would be much easier to implement if we had new RRs like (e.g.) > "SSOP" and "SSMOD" and placed them inside additional section. We could > get the same semantics by creating a DNS message with all sections empty > except "SS*" RRs in additional section. Overhead on wire is negligible > and it makes implementation much easier and safer (because the normal RR > handling code is battle-tested already). > > For these reasons I propose to move to standard RR format to enable code > re-use. Thank you for considering this. The break from standard RR format is intentional, and in large part to avoid the tendency to overload the existing meaning of RR fields as was done with EDNS (i.e. the use of the CLASS field to carry buffer size, and putting bit fields and extended RCODEs into the TTL field). It also (intentionally) prevents *mixing* of SS* TLVs and normal RRs within a session signalling message (or indeed vice versa, putting SS TLVs into a standard QUERY message). Yes, it'll need some new code, but it's not difficult code (indeed it'd be very similar to the code for parsing the RDATA of an OPT RR). I think the cost of that extra bit of code is outweighed by *not* needing extra code in the standard packet handling path to cope with rejecting mixed packets. Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
