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

Thu Apr 30 17:47:48 UTC 2020

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.