Sorry for not having seen this long ago, and thanks for nudging me offline about it.
On Feb 8, 2025, at 07:30, Peter Thomassen <pe...@desec.io> wrote: > Anyway, if objects are to be avoided, the repetition of "add" and "delete" in > each update array can also be prevented by allowing multiple record-data > (zone-data) values: > > [ ..., [ ["add", "foo.example MX 10 mail1.test.", "mail.foo.example MX 20 > mail2.test."] ] ] > > This structure is enabled because the record-data is now a string and no > longer a variable-length list of fields, freeing up that degree of freedom. > It also prevents comments etc. > > (I'd still permit multiple "add" or "delete" update arrays; I just would not > mandate that an update array can only add/delete a single record.) This is fine too. I don't see a strong reason to do one of the other. > Unrelated: Is a DUJ request valid which adds a record and then deletes the > same? If yes, would it be valid if the order of the add and delete arrays > were reversed? It is "valid", but the the DNS operator doesn't have to actually process it. Or anything. As the draft says: "A DNS operator SHOULD tell a user about every change made from a DUJ." I could strengthen that to also say "A DNS operator may reject a DUJ for any reason, such as if it adds and then deletes the same record." --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
