[NCAP-Discuss] Draft final Study 1 report: "re-registered name collisions"

Thu Apr 30 17:54:54 UTC 2020

Hi all,

Sorry to be late to the several discussions (it has been hard to track the group since the most recent scheduled meeting time makes it impossible for me to join the weekly calls).

I am in the process of writing a detailed review of the document, so I plan to have several in-line/substantive comments.  Among them is this issue.  Regardless of this definition's origins, I have to agree that this does _not_ seem like a name collision, to me either.  For example, I don’t get to report a break-in to my apartment after my lease expires, I move out, a new person signs a lease and moves in.  In my humble opinion, the treatise on this in the report follows if-and-only-if (iff) the report is a literature survey (which was, I believe, its stated intention).   The follow-on conclusions that it presents results from investigations, and its conclusion that follow-on research should _not_ be conducted, calls its scope back into question.  I fear it doesn’t make sense to try and have it both ways.

Just my quick (err, not as quick as I had hoped) 0.02,

Eric

> On Apr 30, 2020, at 1:47 PM, Danny McPherson <danny at tcb.net> wrote:
> 
> 
> Matt,
> I would also highlight in Jay's email that you quoted below he states "We can agree the exact text later." -- I believe this constitutes "later".
> 
> I think it is unfortunate that it's conflicted and wasn't resolved then and we should correct it given the implications on scoping.
> 
> I believe two options are 1) either the definition needs to change and some explanation of what's colliding added, or 2) "re-registrations" should be considered out of scope -- as the current definition clearly suggests - I believe those are the options.  I am also not talking about bitflips as I was below as I could _almost argue that either way, just "re-registrations".
> 
> 
> -danny
> 
> 
> On 2020-04-30 13:04, Danny McPherson wrote:
>> Top post only.
>> I understand and remember that Matt.  What I'm saying is that that
>> item technically does not align with the definition and what's
>> considered in scope by the RFP.  Should the design group and work
>> product here not point out that disconnect [error] before this is
>> finalized?
>> Otherwise, can someone explain to me how re-registrations are in scope
>> of that definition?
>> -danny
>> On 2020-04-30 12:59, Matt Larson wrote:
>>> In scope, but see below. Karen is working from the consensus
>>> definition of name collision developed by SSAC and this group, which
>>> is here:
>>> https://docs.google.com/document/d/1h1iuouwwmzitjyFlEPgJHLabgxhdTQTo7Ehfd1v1CBo/edit
>>> Quoting from that document:
>>>> Scope of Inquiry for the Name Collision Analysis Project
>>>> *
>>>> In scope and subject of data studies
>>>> These are situations that fall under the high-level definition of
>>>> name collision, which will be examined in depth through data
>>>> analysis as part of this project.
>>>> *
>>>> User Alice intentionally uses .EXAMPLE in a non-RZM context and
>>>> .EXAMPLE is now delegated in the public DNS.  User Alice suffers
>>>> adverse impact as a result.     *
>>>> User Alice unintentionally uses .EXAMPLE in a non-RZM context (for
>>>> example as the result of a software behaviour) and .EXAMPLE is now
>>>> delegated in the public DNS. User Alice suffers adverse impact as a
>>>> result.
>>>> *
>>>> Registrant Alice uses EXAMPLE as a label anywhere except as a
>>>> non-RZM TLD, and relies on search list processing where the label
>>>> EXAMPLE is the terminal label, as an intermediate step in that
>>>> search list processing. (e.g.  User searches for
>>>> dashboard.example.com [1] by typing in dashboard.example) .EXAMPLE
>>>> is now registered in the public DNS and the search list processing
>>>> behaviour of Alice now changes.
>>>> *
>>>> In scope but not intended to be the subject of data studies
>>>> These are situations that fall under the high-level definition of
>>>> name collision, but are not necessarily related to the introduction
>>>> of new domains and are not intended to be examined through data
>>>> analysis or in any other way, unless a compelling case is agreed at
>>>> a later stage.
>>>> *
>>>> Registrant Alice uses EXAMPLE.COM [2] (or EXAMPLE.TLD where TLD is
>>>> any current TLD in the public DNS) and .EXAMPLE is now registered in
>>>> the public DNS.  Registrant Alice now receives multiple queries as a
>>>> result of search list processing of users of domains under .EXAMPLE
>>>> *
>>>> Registrant Alice uses .EXAMPLE as a TLD in the public DNS and then
>>>> lets the registration expire.  Registrant Bob then registers and
>>>> delegates .EXAMPLE. Traffic intended for Alice’s use of .EXAMPLE
>>>> is now received by Bob’s use of .EXAMPLE
>>>> *
>>>> Registrant Alice uses EXAMPLE.COM [2] and then lets the registration
>>>> expire.  Registrant Bob then registers and delegates EXAMPLE.COM
>>>> [2]. Traffic intended for Alice’s use of EXAMPLE.COM [2] is now
>>>> received by Bob’s use of EXAMPLE.COM [2]
>>>> *
>>>> Out of scope
>>>> These are situations that some may regard as falling under the high
>>>> level definition of name collision, while others may disagree.  For
>>>> the avoidance of doubt these are specifically listed as out of scope
>>>> for this project.
>>>> *
>>>> Registrant Alice uses .EXAMPLE as a TLD in the public DNS.
>>>> Registrant Bob registers and delegates .EHAMPLE as a TLD in the
>>>> public DNS.  Alice now receives bit flip traffic intended for Bob
>>>> and vice versa.     *
>>>> General IDN confusion issues
>>> The mention of "data studies" in B above is the reason for this text
>>> in the report at the end of Section 2, which you quoted in your
>>> original message:
>>>> All four of these types of name collisions are in scope for Study 1.
>>>> Only duplicate name collisions and shortened name collisions (types
>>>> A.a, A.b, and A.c from the RFP) are in scope for Section 5 of this
>>>> report (on data sets for Studies 2 and 3). No other types of name
>>>> collisions are in scope for any parts of Study 1.
>>> This topic has been discussed below on this list. Please see two email
>>> messages below from May 2019.
>>> Matt
>>>> Begin forwarded message:
>>>> FROM: Jay Daley <jay at daley.org.nz>
>>>> SUBJECT: [EXT] RE: [NCAP-DISCUSS] PLEASE REVIEW THE STUDY 1 PROPOSAL
>>>> DATE: May 22, 2019 at 4:34:16 PM EDT
>>>> TO: Danny McPherson <danny at tcb.net>
>>>> CC: Matt Larson <matt.larson at icann.org>, <ncap-discuss at icann.org>
>>>> Hi Danny
>>>> On 23/05/2019, at 7:52 AM, Danny McPherson <danny at tcb.net> wrote:
>>>> On 2019-05-22 11:00, Matt Larson wrote:
>>>> Folks,
>>>> Please review the NCAP Study 1 proposal
>>> (https://docs.google.com/document/d/15f1Kh2vuY0yF9SelocGrPOguYPXDeFYZ0lTqx3fU_gI/edit
>>>> [docs.google.com] [3])
>>>> before today's call, if possible.
>>>> In particular, please note comments from Steve Sheng and me.
>>>> Thanks and talk to everyone in a few hours,
>>>> Matt,
>>>> A little more time to review would have been helpful but regardless,
>>>> I think you've got most of items 1.b and 1.c totally backwards.  TO
>>>> suggest new registrations of expired domains are in scope of name
>>>> collisions surprises me, and that bit flips or other things that may
>>>> result in persistent collisions are out of scope seems to ignore the
>>>> immense amount of SSAC work that led to this WP.  I think perhaps
>>>> both may be out of scope but where you arrived with expired domains
>>>> being re-registered as in scope confuses me, can you explain the
>>>> genesis of that in any dialog we've had or in the SSAC direction
>>>> provided?
>>> I drafted this text based on extensive discussion in the SSAC WP that
>>> was set up before this project was opened up.  It was presented on at
>>> two ICANN meetings (as well as multiple SSAC meetings) and referenced
>>> in two discussion group meetings as well as being circulated to the
>>> list.  No it is not backwards, it is exactly as agreed through that
>>> process.
>>> The original SSAC WP consensus on this included the recommended advice
>>> to give, which is basically "this happens all the time in the DNS,
>>> there are other policies that might be applicable but that’s not for
>>> us to say".  We can agree the exact text later.
>>> I should also note that there were a number of calls in the DG for
>>> comments on this document, so this is way past the 11th hour.
>>> best
>>> Jay
>>>> Begin forwarded message:
>>>> FROM: Danny McPherson <danny at tcb.net>
>>>> SUBJECT: [EXT] RE: [NCAP-DISCUSS] PLEASE REVIEW THE STUDY 1 PROPOSAL
>>>> DATE: May 22, 2019 at 4:57:04 PM EDT
>>>> TO: Jay Daley <jay at daley.org.nz>
>>>> CC: Matt Larson <matt.larson at icann.org>, ncap-discuss at icann.org
>>>> On 2019-05-22 16:34, Jay Daley wrote:
>>>>> I should also note that there were a number of calls in the DG for
>>>>> comments on this document, so this is way past the 11th hour.
>>>> Apologies to both, I now recall that the disclaimer satisfied my
>>>> previous objections (i.e., "In scope but will be addressed with
>>>> general advice and not subject of data studies.")
>>>> That said, IF things in the documents we post for comment are
>>>> prohibited and off-limits for comment let's quarantine them and
>>>> convey as such, else you'll see my insanity ensue...  :-P
>>>> -danny
>>> Links:
>>> ------
>>> [1] http://dashboard.example.com
>>> [2] http://EXAMPLE.COM
>>> [3]
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_15f1Kh2vuY0yF9SelocGrPOguYPXDeFYZ0lTqx3fU-5FgI_edit&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=xhCX8vQGcsNMzNMbgIokNle9Mpt6sQ45tM98iwh4H0w&m=tg-rp3wTBAwM-AMwPTMwqQh2ElUtEjOoPDL6TnLxRfY&s=s9_F1SlGdOstniJdCs5BvjAsgS6-auiDi3MAMxpU-3Q&e=
>> _______________________________________________
>> 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.
> 
> _______________________________________________
> 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.