[gnso-rds-pdp-wg] IMPORTANT: Invitation for Poll from 29 August Meeting

[Farell Folly]

@Andrew

What if we use the second possible way of understanding *optional* :

<<This won't be provided unless you know it >> instead of :

I am suggesting that
if the policy is that "optional" means "this will be provided unless
you don't know it",

Le 3 sept. 2017 07:48, "Andrew Sullivan" <ajs at anvilwalrusden.com> a écrit :

Hi,

On Sun, Sep 03, 2017 at 12:18:43AM -0400, Greg Shatan wrote:
> If this definition of optional made it all the way through to consensus
> policy, I don't think we can simply reject it even if it seems
"unnatural."

I am not even a little bit convinced that ICANN consensus is a good
way to remake the nature of human expression in English, never mind
the way to determine what is natural.  Nevertheless,

>  Policy should be conceptually consistent with past policy wherever
> possible.

I am not suggesting that we change the policy.  I am suggesting that
if the policy is that "optional" means "this will be provided unless
you don't know it", then we are not being conceptually consistent with
the English language, and that therefore the policy will find itself
running up against the practical problems presented by humanity.

> I don't think "optional to collect" is quite the right characterization.
> It's more "mandatory to collect if present

Present _where_?  In some obvious sense, _every_ optional element we
might think of is somehow available, even if the answer is "none".
There is a fact of the matter out there in the world, and what we're
trying to do is put some such facts in a database.  I am trying to
argue that we must require (1) facts that we need (2) for some
legitimate purpose and (3) that we can reasonably expect will be
correct.  If data is only "optional" when it doesn't exist, then it's
not optional: it's required, but it might have a NULL value because it
might not apply to the data in question.

> I also don't agree with the statement that "the collection side of the rds
> is whatever the registry does," for two reasons.  First, registries
collect
> information for their business purposes that are not part of the RDS.

I've been asking about this now for something around a month, and I
still don't seem to have a crisp answer.  It is entirely clear that
registrars collect, as part of every registration action, data that
ought not to be part of any RDS.  What data do _registries_ collect as
part of a registration action (and not incidental to it such as
billing events) that is not effectively the data set on which the RDS
ought to be operating?  For these purposes, assume all registries are
thick. (To get the outcome one might want, the RDS data could be much
more widely distributed, but let's just assume it's one thick registry
for every TLD.)

> Second, the RDS is being collected for directory purposes -- ultimately
for
> the registrants and other users of the RDS, so the RDS is not an outgrowth
> of registry collection purposes; it's an effort that the registries
> undertake because the policy requires it (which in turn is because it is
> highly useful for a variety of reasons).

This appears to be a suggestion that there is an RDS that, quite
independent of the registration system, has an independent demand with
a need to be satisfied.  I'm quite uncomfortable with that assertion.
Most especially, the idea that anything happens on the Internet
exclusively (or even mostly) because "policy requires it" suggests to
me that I must be misreading, since I know you (Greg) know that to be
crazy.  What did I miss?

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/20170903/ee8159d5/attachment.html>