[gnso-rds-pdp-wg] Some reg'n data I think necessary (was Re: GNSO Next-Gen RDS PDP Working Group teleconference)

Sun Mar 20 23:29:33 UTC 2016

Amen!

-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================

On Sun, Mar 20, 2016 at 12:16 PM, Andrew Sullivan <ajs at anvilwalrusden.com>
wrote:

> Dear colleagues,
>
> On Sun, Mar 20, 2016 at 09:30:41AM -0500, Carlton Samuels wrote:
>
> > Is there a need for the collection of registration data, and, to
> > what end?
>
> It is important for operators on the Internet to be able to contact
> operators of other domains, in order to deal with abuse, network
> misconfiguration, and so forth.  Most obviously, for instance, if a
> domain has some sort of mail loop problem there is literally no way to
> contact the operator of the domain except off-Internet.
>
> Some participants in this discussion appear to believe that we need to
> prove everything from first principles before moving on to practical
> questions.  Even if I understand such an impulse, I think it amounts
> to a denial of service on this effort.  Therefore, I hereby offer some
> basic assertions, which I make in decreasing order of (my) commitment
> to them.  I believe that each of these is relevant to technical
> operations of Internet domains.  Accepting even one of these premises
> allows us to cut off (by entailment) any discussion of whether any
> registration data needs to be collected at all, and starts us on a
> discussion of how such data ought to be exposed.  (I am leaving aside
> issues of trademark and so on, because quite frankly I think the
> extension of trademark issues into the domain name space was a
> terrible mistake; but I'm sure someone else could come up with a list
> similar to what I offer here while including trademarks.  There are
> many lists in the world; this is mine):
>
> • Every domain on the Internet must have name servers in order to
> function.  The RDS ought to contain those name servers so that, in the
> event of technical problems, other operators can detect whether there
> is a gap between what the registry contains and what the authoritative
> servers contain.
>
> • Many domans are signed, and in a signed domain that delegates the
> delegation will have a DS record.  The RDS ought to contain the DS
> record for the same reason the RDS ought to contain the name servers.
> In signed domains today, this may be even more important than the NS
> records, given the frequency of DNSSEC misconfiguration (but I expect
> this issue to decline over time).
>
> • Every name server has someone responsible for its operation.  The RDS
> ought to contain contact information for a given domain or the name
> server or (preferably) both, so that in the event of serious
> malfunction such that interoperation is impossible there is some
> mechanism for out-of-band contact in order to rectify the problem.
>
> • In shared registration systems, it is usually (always?) the case
> that registrations are not single-occasion, but instead are
> registration at a point in time for some term.  It is therefore
> necessary, for troubleshooting interoperation, to know when a name's
> registration is expiring and also when it was last updated (to
> troubleshoot recent problems that might be related to changes).
>
> • In any registry using EPP, every domain has an authInfo associated
> with it in order to help authorize transfer requests.  This data must
> be collected by the registry (it's part of the protocol.  Please don't
> tell me we're going to investigate whether EPP is the correct
> protocol.  It's the one we have).
>
> • In gTLDs, most (all?  I know there have been exceptions in the past,
> because I made the entries in the relevant database) registrations are
> registered through a registrar.  There are two reasons to be able to
> learn the registrar of a name.  It is necessary for other Internet
> parties to be able to learn the registrar in order to deal with
> registration problems and other operational problems where the name
> server contact was inadequate.  It is necessary for other registrars
> to be able to learn the existing registrar in order to facilitate
> registrant-demanded transfers.  (This second reason of course doesn't
> require the appearance in the RDS, but we are talking about why
> registration data needs to be collected in the first place.)
>
> • Every registration is a registration by someone.  Some registrations
> are the source of abuse against other networks, and it is sometimes
> necessary to be able to learn the real information about such a
> registrant in order to stop such abuse.  Note that this is not an
> argument that such data need automatically be available anonymously
> through an RDS; just that it be collected.
>
> • In gTLDs, most (all?  I know there have been exceptions in the past,
> because I made the entries in the relevant database) registrations
> include some cost that accrues to the registrant in exchange for the
> registration.  The identities of the parties responsible for keeping
> the data up to date and for paying the registration are required in
> order to ensure continued operation by the same party at the time of
> expiry of a registration term.  This ensures the utility of a domain
> name, by making it a useful name for a particular network over time
> (imagine the operational confusion if, when sending email to someone,
> you first had to figure out whether they were at the same domain name
> as yesterday).  Note that this is not an argument that such data need
> automatically be available anonymously through an RDS; just that it be
> collected at least by the registrar.
>
> > Let us exercise good common-sensical judgment and resist the temptation
> to
> > re-invent wheels.
>
> I agree.  AFAICT, the above list covers what is normally accessible in
> the whois output of contracted thick registries today, and indicates
> places where anonymous access seems optional.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160320/d679ec5a/attachment.html>