[NCAP-Discuss] Reminder - Please review the Data Sensitivity Study

Mon Jan 10 16:06:02 UTC 2022

Hi Tom,

The problem has always been guessing what the future will look like. Regardless of how much a certain string (for example) is analysed, there will always be unknown unknowns that pop up. SSAC have already described this a number of times, and because of this I feel we have to think of two different things here, but first, lets talk about what we mean by "delegation".

In the context of name collisions we are using this in the DNS sense. Do not mix this up by overloading this with the business sense, i.e., the string has been allocated to the applicant. All of the NCAP work is pre-allocation. This is critical to understand.

Second, it’s not about recursive resolver data. It’s about a full picture of the data from the infrastructure. Over the past decade one change that has happened in the infrastructure is the presence of recursive resolver. So, our critical result is that we need data at the root servers to see a full picture because this one change has shown that changes to the infrastructure change the data picture. We don’t know what changes might come about in the future. We can certainly speak more about the ones we know about today, but we don’t know what we don’t know.

Third, yes, privacy and legal concerns exist today. These are additional factors on top of the technical one that will be challenging to resolve, if at all. Useful to note but not material to the technical decision at hand.

At the same time, the only thing we can do is to do an analysis based on data at hand, that give ok/nok before allocation. A different thing is to ensure there are enough data collection, safe guards, and what not (both technical and legal/contractual) so that if unknown things happens, actions can still be taken.

Remember Donald Rumsfeld that said:

> There are known knowns. There are things we know we know.
>
> We also know there are known unknowns. That is to say, we know there are some things we do not know.
>
> But there are also unknown unknowns, the ones we don't know we don't know.

   Patrik

On 5 Jan 2022, at 20:54, Tom Barrett via NCAP-Discuss wrote:

> Hi Matthew,
>
> I was unable to attend today's meeting due to receiving zoom error 1001 via various devices and browsers.
>
> I wanted to make just one observation and suggestion. I'm having some difficulty with the definitiveness of this conclusion:
> " A complete and accurate risk assessment of a string’s name collision potential cannot be determined prior to the string's delegation."
>
> I can appreciate the challenge of currently accessing public recursive resolver data as summarized here : "in part due to legal and privacy concerns, it is likely that public resolver data will be even more obscure or scarce in the future.".
>
> However, since this is not a technical issue but rater a "speculative"
> commercial issue, it appears it might be a solvable problem that could be addressed well before ICANN starts accepting applications for the next round (~in 4-5 years).
>
> What are your thoughts about qualifying your conclusion somewhere along the lines of:
> " A complete and accurate risk assessment of a string’s name collision potential cannot be determined prior to the string's delegation, unless ICANN is able to generate or obtain public recursive resolver data prior to the next round of new gTLDs."
>
> best regards,
>
> Tom
>
>
>
>
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Tue, Jan 4, 2022 at 8:12 AM Thomas, Matthew via NCAP-Discuss <
> ncap-discuss at icann.org> wrote:
>
>> All,
>>
>>
>>
>> Happy New Year!
>>
>>
>>
>> As promised here is a gentle reminder for the group to review the Data
>> Sensitivity Study [1] (PDF version also attached here). We will be
>> discussing the document at the next NCAP DG call on 1/12/2022. It is
>> important we reach a final version near the 12th so we can release the
>> document for public comment in conjunction with the already reviewed CORP,
>> HOME, and MAIL case study.
>>
>>
>>
>> Best,
>>
>>
>>
>> Matt Thomas
>>
>>
>>
>> [1]
>> https://docs.google.com/document/d/1sLPrBn8T6ym7gumySHeWG9THSGSRoEeKldv3uRMMy6Y/edit?usp=sharing
>>
>>
>> _______________________________________________
>> NCAP-Discuss mailing list
>> NCAP-Discuss at icann.org
>> https://mm.icann.org/mailman/listinfo/ncap-discuss
>>
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). You can
>> visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>
>
>
> -- 
> Thomas Barrett
> President
> EnCirca, Inc
> +1.781.942.9975 (office)
> 400 W. Cummings Park, Suite 1725
> Woburn, MA 01801 USA
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220110/800d0c70/signature.asc>