On 1/30/24, 01:14, "DNSOP on behalf of Ralf Weber" <dnsop-boun...@ietf.org on behalf of d...@fl1ger.de> wrote: >... but having a > record type that is extensible from the start ...
Designing in extensibility is a very good idea, ah, essential idea, but isn't a no-brainer. Start by asking and documenting: What information is needed at a DNS delegation? There's the service address of course. There's a security context to be related. And there are arguably other meta-data to include. Consensus on this answer needs to be achieved, from this we can determine whether the construct of the resource record is necessary and sufficient. Because the draft only defines DELEG via examples, I need to ask this question this way: The RDATA has three fields - <a number> <a domain name> <space-separated list of keyword=value elements> Is there going to be an assumed "standard set" of keywords? (And a defined manner to know how to deal with unknown-to-the-receiver keywords.) In asking this I'm thinking of the early experience with message compression, that is was supposed to only work for the types defined in the base DNS documents [those labeled STD 13] but then compression was accidently/inappropriately added for more, which led to a mess that "Handling of Unknown DNS Resource Record (RR) Types" had to deal with. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
