[gnso-rds-pdp-wg] The Whois roles are not well defined

Fri Feb 16 01:56:23 UTC 2018

Fair point.  Rob Golding says "Account Holder" is the term commonly used.
This seems fine to me -- descriptive, accurate and unprovocative.  I'll use
it in the future.

Steve

On Thu, Feb 15, 2018 at 8:15 PM, Chuck <consult at cgomes.com> wrote:

> Thanks Steve.  I am glad to see that a few members have already responded
> and hope others will as well.
>
>
>
> I just want to share a concern about using the term ‘controller’.  The
> term ‘data controller’ that is key for the GDPR could probably be easily
> confused with ‘domain controller’.  That said the idea of coming up with a
> better term seems reasonable.
>
>
>
> Chuck
>
>
>
> *From:* gnso-rds-pdp-wg [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On
> Behalf Of *Steve Crocker
> *Sent:* Thursday, February 15, 2018 1:05 PM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* [gnso-rds-pdp-wg] The Whois roles are not well defined
>
>
>
> Almost all of the discussion around whois has been based on implicit
> acceptance of the roles of registrant, admin contact and tech contact as if
> these had definite meaning.  They don't.
>
>
>
> The person who actually controls the domain registration and the
> associated parameters, i.e. name servers, etc. is the person who has access
> to the account with the registrar.  I don't know if there is widely agreed
> upon name of this role, so I'll call her the domain controller.  If this
> group prefers a different name, I'll happily switch.
>
>
>
> It's the domain controller who populates the registrant, admin and tech
> fields.  Most of the time, the names and contact information that is put
> into these fields is reasonably related to the common sense notion of what
> these terms mean, but unless I have missed something, there is nothing in
> either the rules or the operational practices that forces these to be
> meaningful.  In the extreme, the controller can put in the names of people
> who have NO relationship with the domain.  Viewed from this perspective,
> rather than decrying the high error rates, it might be more appropriate to
> be amazed at how well this system works.
>
>
>
> When the whois system was first created, the net -- and we're talking
> about the Arpanet, not the full blown Internet -- consisted of several
> dozen time-shared computers, each of which support several dozen users.
> The tech contact was what we'd now call the system administrator (sysadmin)
> and the admin contact was someone who had administrative authority over
> both the operations and the users.  The list of contacts was intended to
> make it easy for the relevant people in authority to get in touch with each
> other when there was a problem.
>
>
>
> Those terms have been transliterated to the domain name system and scaled
> from hundreds to hundreds of millions.  Nothing really survives being
> scaled up by a factor of a million without undergoing serious and
> substantial reworking.
>
>
>
> In my view, the extensive and overwrought discussion about who should have
> access to the contact information, how to validate the information, and how
> to reconcile all of this with privacy laws is troubled because there really
> isn't a firm foundation at to what this contact information means.  The
> operational questions for contact information is fundamentally what
> obligation does the person designated in a particular role have when she's
> contacted, who should be allowed to contact the person, and under what
> circumstances.
>
>
>
> There is, of course, one particular role that is well defined.  It's the
> billing contact.  If the registrar sends a message to the billing contact
> and says the bill hasn't been paid, the billing contact either takes care
> of the problem or the registrar shuts down the account.
>
>
>
> There is also a reasonably well defined sequence related to domain name
> transfers.  Is there more that is well defined?
>
>
>
> What are the implications of this line of reasoning?  Well, for starters,
> what happens if we simply remove the admin and tech contacts?  If there is
> an argument for continuing their existence, can we base it on operational
> authorities and responsibilities?
>
>
>
> Another, quite important but less obvious implication is to look at what
> information is NOT there that should be.  The current ICANN contractual
> model is based on registries and registrars but pays no attention to name
> server operators.  It's quite common for the registrar to operate the name
> servers for the registrant, but it is also quite common for the registrant
> to either operate her own name servers or to use a third party.  There are
> companies that specialize in providing this service, and they are an
> important part of the ecosystem.
>
>
>
> Why does it matter that name server operators are not explicitly visible
> in the ICANN contractual model and registration data base?  Because the
> name server operator sometimes needs to change the information in the
> registry that's associated with the domain name.  There are two significant
> cases.  One is when the name server operator changes the set of name
> servers associated with a domain name.  This doesn't happen frequently, and
> when it does it usually affects a large fraction or all of the name server
> operator's customers.  When that happens, the revised list of name servers
> has to be communicated to the registry and be published in the parent zone.
>
>
>
> Under the ICANN model, the only path for communicating with the registry
> is via the registrar, and the only path implemented by registrars is via
> the account holder, i.e. the person I called the controller.  This means
> when a name server operator makes a change to its set of name servers, EACH
> of the name server operator's customers has to process an email message
> from the name server operator and make a manual change to the entry in her
> account.  This is time-consuming, labor intensive and error prone.
>
>
>
> The other case is related to DNSSEC.  The signatures associated with
> DNSSEC have expiration dates.  If the name service is being provided by a
> name server operator, it will be the name server operator that will
> generate a new key and create a new DS record on a regular schedule and .
> This requires putting the new DS record in the parent.  Again, since the
> only path is through the registrar...
>
>
>
> here are proposals for additional protocols to automate this process, but
> these have some complexity due to the need to work around the clumsiness of
> adhering to the limited business model.  It ought to be possible for the
> domain controller to explicitly designate the name server operator and to
> authorize the name server operator to send changes to the name server
> records and/or the DS records whenever necessary.
>
>
>
> For those of you who have read this far and are wondering whether this
> really belongs in a discussion about RDS, the answer is yes,  The RDS is a
> portion of the overall operation of the domain name system.  It provides
> contact information for the essential functions of the system.  In the
> ICANN system, the registrars are contracted parties and the name server
> operators are not, but that does not address the need for a more orderly
> operational relationship among these parties.
>
>
>
> More to come.
>
>
>
> Steve
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180215/5e9eb36c/attachment.html>