On 12.09.14 04:24, Andrew Sullivan wrote: > On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote: >> >> It was curious to see that a to-be-unnamed TLD registry, a newcomer >> to the scene many years after the holy wars that ended up defining >> the current RFCs, writing completely new code, mentioned that they >> found attributes to be a better option > > Well, note, the RFCs actually allow you to do one or the other, so > there was no "victor" in the war. Many people when designing a new > registry think attributes are better because they don't create > cross-object links. If you come from the database side of the house > (which I do), you are given shudders because of the potential for data > inconsistency in glue. Lots of new registries don't have a glue > problem early on, and so this never seems like it's worth worrying > about. That's the real reason I prefer the host-object approach. But > like Frederico, I don't want to reignite a controversy.
If you truly did not want to re-ignite this, you would not have stated opinion -- there is a reason both ways end up in the RFCs, as both work and it's all a matter of diligence (and software). Here is mine The host-object approach is the worst choice, ever. It suits certain operators idea of 'visibility', but does not help with data consistency. Consider the scenario of domain.com delegated to pns1.otherdomain.com and pns2.otherdomain.com. However otherdomain.com is delegated to ns1.otherdomain.com and ns2.otherdomain.com. Obviously, otherdomain.com is the 'service provider'. In theory, the ns1.otherdomain.com and ns2.otherdomain.com need to have glue records. Everything else is extraneous, vanity stuff if you will and add to the maintenance and data consistency burden. variant 1: ns1.otherdomain.com and ns2.otherdomain.com are attributes to the otherdomain.com object. Everything is as it should be. Whoever controls the domain object, controls the glue. The domain object is gone, so is the glue. Perfect! variant 2: ns1.otherdomain.com, ns2.otherdomain.com, pns1.otherdomain.com and pns2.otherdomain.com are all host-objects. Who owns them? Which of them can/do have glue? True, a much more complex (read: more prone to errors and harder to verify) piece of software could handle all the mess. Most of the cases of EPP software are however quite trivial. What happens when otherdomain.com gets deleted? Which host-objects disappear, if any, which glue remains, who ends up managing those records, etc. Zombie host-objects aren't that impossible, right? As a Hollywood cop would say "follow the money". Who has most interest for the host objects to exist? Certainly, not the typical domain name owner. >> better, but for me it indicates that the role in the value chain can >> play a part in which option is preferred. > > Yes. Interoperability is way more important that just about anything > else on the Internet. You mean... whose operations would be cheaper? :) The bigger fish wins most of the time. Daniel _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
