registrar Only in TLD that have a registry/registrar model. (And we are only concerned about gTLD in this WG, right?)
Yes, as a WG we're essentially only concerned with gTLDs under ICANNs remit, so they all have a Registry/Registrar model (even if the Registrar on a brand-tld could be the Registry)
auth-code Also note that this is not baked into DNS technology or anything like that, but is only an artifact of a current registrar transfer system. Fundamentally this is a way to authenticate the registrant, which is what the registry really needs.
It's less about authentication of the Registrant, and more about ensuring authorisation has been gained for the Transfer.
status What does this mean?
Domains are (currently) required to have "status" code(s) relating to locks, udrp etc - but on further reflection it's not absolutely necessary for the domain name to exist or function (although will be there "internally" at the Registry)
And for it to be of some "functional" use: Optional nameservers
And also optionally: DS record (or DNSKEY or other cryptographic information which can be used to produce a DS record for DNSSEC).
Is the most-effective Denial-Of-Service methodology for domains actually needed for it to "work" though (leaving aside how many dont work because of dnssec) ? Probably. So ... To Exist = * domain-name (what it is) * registrar (who manages it) To Function [optional] = * nameservers * ds-stuff To Manage / Needed for Internal Systems = * transfer authentication [optional dependant on registration model] * expiry date * status
As a final note, if there are no registrars then everything except for the expiry date can be obtained from the DNS itself.
In principle I agree - I'm sure we can argue the minutiae of detail about whether it needs to be somewhere else for DNS to work though Anyone else have items to add which are _required_ rather than one-or-more of wants/nice-to-have/needed-for-my-business-model etc ? Rob