[gnso-rds-pdp-wg] [renamed] Key early questions

Sam Lanfranco sam at lanfranco.net
Wed May 11 15:54:11 UTC 2016


Just a quick short "keep it simple" comment on both TXVB's and Andrew 
Sullivan's postings:

The "why we_need_an_RDS" is a legitimate question and it has two parts.

Part one is why does ICANN need what data, and beyond that, and largely 
outside ICANN's remit, part two is why do Registries and Registrars need 
data.

As far as ICANN is concerned the question is only around the data ICANN 
needs and the terms under which it is provided, stored, private and 
secure, terms of access by legal authorities etc.
ICANN can impose data requirements via its contracts with contracted 
parties and those may or may not be allowed to stand by the authorities 
in the countries where registries and registrars are located.

As the Irish have pointed out, some of what ICANN requires in its 
contracts is contrary to national law, even though enforcement has been 
lax. That is unlikely to continue, so whatever ICANN thinks it needs as 
it works through this gnso-rds-pdp-wg process, looking over the ICANN 
remit "fence" at legislation elsewhere is a judicious idea.

As for Andrew's point that operators have need for data to conduct their 
business, that "need" breaks down into three categories:
1. There is the data needed to meet ICANN's contracted requirements.
2. There is the data needed to conduct the business of dealing with 
clients as registrants (invoices, billing, payment, etc.).
3. There is desired data to conduct other marketing and innovative 
aspects of being a contracted operator (registry, registrar).

ICANN's focus should be primarily on category #1, with due respect to 
the costs and compatibilities with Registry and Registrar needs.
Category #2 is up to the contracted parties and they can compete or 
share best practices as they see fit, like any other industrial sector.
The only interest ICANN should have in Category #3 is to remain alert to 
data uses that may compromise the integrity of the DNS system and engage 
contracted parties when issues arise.

Rest assured that national and regional authorities will be also 
watching all of this with greater diligence.

Sam

On 5/11/2016 7:07 AM, TXVB wrote:
> I have this concern also. That was the #1 item to consider, per the 
> charter before plowing ahead.
>
>
>
>
>
>
> -------- Original Message --------
> On May 10, 2016, 1:16 PM, Andrew Sullivan wrote:
>
>
>     Hi,
>
>     I'm slightly concerned that we are forgetting in this discussion why
>     we _need_ an RDS in the first place.
>
>     On Tue, May 10, 2016 at 10:59:29AM -0400, Sam Lanfranco wrote:
>     >
>     > ICANN has business interests in defining what data to collect,
>     accessible by
>     > whom and under what conditions. It also has business interests,
>     from within
>     > its remit, in the data relationship with its contracted parties.
>     > However, ICANN’s contracted parties reside within national
>     jurisdictions,
>     > and the relevant data is hosted within national jurisdictions,
>     so ICANN
>     > cannot unilaterally define what constitutes legitimate data
>     policy within
>     > its business interests.
>
>     All of the above is something I agree with, but there's another
>     important point. For good, sound, plain old technical reasons, it's
>     important that operators be able to contact each other outside of the
>     Internet, so that when stuff breaks it's at least logically possible
>     that one could try to fix it.
>
>     The key point is that this is not some peculiar business interest of
>     ICANN, but instead a fundamental interest of anyone who uses the DNS
>     (i.e. approximately anyone who uses the Internet). It's basic to why
>     we have ICANN at all.
>
>     None of this is an argument that _all_ the information in any
>     particular RDS policy is what ought to be in the RDS. But at the same
>     time, it seems to me that some views about RDS treat every data field
>     as if it's a simple matter of political negotiation or something like
>     that. They're not all that way. As an operator of actual technical
>     infrastructure, I need to be able to contact someone who is causing
>     problems on my network, and that ability to contact had better not
>     depend on the Internet since the problem in question is likely to
>     result from some sort of interoperation failure in the first place.
>     Therefore,
>
>     > Some will brand this as the “fracturing of the Internet”. It is
>     in fact
>     > other jurisdictions taking responsibility for Internet
>     governance outside
>     > ICANN’s remit, but within their remit.
>
>     I don't think that all of this is just about "Internet governance",
>     any more than (say) port number allocations are a matter for Internet
>     governance. Some of it is just a fundamental part of having an
>     Internet at all. Remember, it's an inter-net because of the network
>     of networks part. Interoperation is a fundamental part, not something
>     you get to choose or not from a menu of available policy options.
>
>     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
>
>
>     _______________________________________________
>     gnso-rds-pdp-wg mailing list
>     gnso-rds-pdp-wg at icann.org
>     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>

-- 
------------------------------------------------
"It is a disgrace to be rich and honoured
in an unjust state" -Confucius
  邦有道,贫且贱焉,耻也。邦无道,富且贵焉,耻也
------------------------------------------------
Dr Sam Lanfranco (Prof Emeritus & Senior Scholar)
Econ, York U., Toronto, Ontario, CANADA - M3J 1P3
email:Lanfran at Yorku.ca    Skype: slanfranco
blog:http://samlanfranco.blogspot.com
Phone: +1 613-476-0429 cell: +1 416-816-2852

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160511/d3d975eb/attachment.html>


More information about the gnso-rds-pdp-wg mailing list