On 02/11/2016 22:16, Paul Hoffman wrote: >>> - It feels like combining both class and type into ClassType might be >>> over-optimization. Since Class will almost always be IN, why not just >>> have this as its own object member? >> >> I was also looking at this and there are some values which are very >> common so you could add to the specification "if not specified then X is >> Y" assumptions. > > Arrrgh. I think I now understand that Class/Type tables (Section 7.10) > are a way to say "there are a very limited number of combinations of > Class and Types, so let's combine the two into single entries for > pointing to". If I have that right, then making ClassType a list would > save two bytes per entry in the table.
Yep. That was exactly the intention. Probably not a big saving overall, but a saving.
> --Paul Hoffman, who totally admits that this totally dives into the > format and not the picture of whether it is useful and to whom... I'm impressed anyone is reading it that closely at this stage :-) -- Jim Hague - j...@sinodun.com Never trust a computer you can't lift. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop