<div dir="auto"><div data-smartmail="gmail_signature" dir="auto">@Andrew</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">What if we use the second possible way of understanding *optional* : </div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">&lt;&lt;This won&#39;t be provided unless you know it &gt;&gt; instead of :</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto"><span style="background-color:rgb(239,154,154)"><span style="font-family:sans-serif">I am suggesting that </span><br style="font-family:sans-serif"><span style="font-family:sans-serif">if the policy is that &quot;optional&quot; means &quot;this will be provided unless</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">you don&#39;t know it&quot;,</span></span><br></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Le 3 sept. 2017 07:48, &quot;Andrew Sullivan&quot; &lt;<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a>&gt; a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="quoted-text"><br>
On Sun, Sep 03, 2017 at 12:18:43AM -0400, Greg Shatan wrote:<br>
&gt; If this definition of optional made it all the way through to consensus<br>
&gt; policy, I don&#39;t think we can simply reject it even if it seems &quot;unnatural.&quot;<br>
<br>
</div>I am not even a little bit convinced that ICANN consensus is a good<br>
way to remake the nature of human expression in English, never mind<br>
the way to determine what is natural.  Nevertheless,<br>
<div class="quoted-text"><br>
&gt;  Policy should be conceptually consistent with past policy wherever<br>
&gt; possible.<br>
<br>
</div>I am not suggesting that we change the policy.  I am suggesting that<br>
if the policy is that &quot;optional&quot; means &quot;this will be provided unless<br>
you don&#39;t know it&quot;, then we are not being conceptually consistent with<br>
the English language, and that therefore the policy will find itself<br>
running up against the practical problems presented by humanity.<br>
<div class="quoted-text"><br>
&gt; I don&#39;t think &quot;optional to collect&quot; is quite the right characterization.<br>
&gt; It&#39;s more &quot;mandatory to collect if present<br>
<br>
</div>Present _where_?  In some obvious sense, _every_ optional element we<br>
might think of is somehow available, even if the answer is &quot;none&quot;.<br>
There is a fact of the matter out there in the world, and what we&#39;re<br>
trying to do is put some such facts in a database.  I am trying to<br>
argue that we must require (1) facts that we need (2) for some<br>
legitimate purpose and (3) that we can reasonably expect will be<br>
correct.  If data is only &quot;optional&quot; when it doesn&#39;t exist, then it&#39;s<br>
not optional: it&#39;s required, but it might have a NULL value because it<br>
might not apply to the data in question.<br>
<div class="quoted-text"><br>
&gt; I also don&#39;t agree with the statement that &quot;the collection side of the rds<br>
&gt; is whatever the registry does,&quot; for two reasons.  First, registries collect<br>
&gt; information for their business purposes that are not part of the RDS.<br>
<br>
</div>I&#39;ve been asking about this now for something around a month, and I<br>
still don&#39;t seem to have a crisp answer.  It is entirely clear that<br>
registrars collect, as part of every registration action, data that<br>
ought not to be part of any RDS.  What data do _registries_ collect as<br>
part of a registration action (and not incidental to it such as<br>
billing events) that is not effectively the data set on which the RDS<br>
ought to be operating?  For these purposes, assume all registries are<br>
thick. (To get the outcome one might want, the RDS data could be much<br>
more widely distributed, but let&#39;s just assume it&#39;s one thick registry<br>
for every TLD.)<br>
<div class="quoted-text"><br>
&gt; Second, the RDS is being collected for directory purposes -- ultimately for<br>
&gt; the registrants and other users of the RDS, so the RDS is not an outgrowth<br>
&gt; of registry collection purposes; it&#39;s an effort that the registries<br>
&gt; undertake because the policy requires it (which in turn is because it is<br>
&gt; highly useful for a variety of reasons).<br>
<br>
</div>This appears to be a suggestion that there is an RDS that, quite<br>
independent of the registration system, has an independent demand with<br>
a need to be satisfied.  I&#39;m quite uncomfortable with that assertion.<br>
Most especially, the idea that anything happens on the Internet<br>
exclusively (or even mostly) because &quot;policy requires it&quot; suggests to<br>
me that I must be misreading, since I know you (Greg) know that to be<br>
crazy.  What did I miss?<br>
<br>
Best regards,<br>
<div class="elided-text"><br>
A<br>
<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</div></blockquote></div><br></div></div>