[NCAP-Discuss] The Public Suffix List (PSL)

[Rod Rasmussen]

Thanks Jeff,

And knowing a thing or two about how Jothan and the PSL like to work, pre-notification actually fits in the model, so wouldn’t even be a “stretch”.  I concur with your analysis and conclusions.

Cheers,

Rod

> On Nov 9, 2023, at 11:09 AM, Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org> wrote:
> 
> Team:
>  
> Rolling-up and sharing a number of conversations recently:
>  
> The Public Suffix List (PSL) (https://publicsuffix.org/ <https://publicsuffix.org/>) is a volunteer-maintained list of TLDs and “TLD-like” domains like .com.cc <http://com.cc/>, .co.uk <http://co.uk/>, etc. PSL is lovingly maintained by Jothan and a small group of folks for quite a while now. The uses of PSL vary widely. There are several other similar projects that effectively maintain lists of TLD-like things for one reason or another.
>  
> I believe it is a Finding for NCAP that such projects exist and have lose and widely varying relationships with the collisions phenomenon.
>  
> PSL typically populates itself in one of two ways: (1) Observing IANA actions; and (2) Voluntary submissions. In the case of new gtlds, absent advance notification from ICANN/TRT, PSL would find out about the TLD at the time of an IANA action (the first trial delegation by the TRT). I think there is only one NCAP consideration beyond the Finding – should ICANN/TRT “pre-advise” PSL (causing PSL publication prior to IANA action), or simply remain silent and allow PSL to pick it up in normal course?
>  
> Like everything Collisions, there is no clear choice and arguments could be made either way. Issues related to end software updates against PSL snapshots and the associated time lags are both unknowable and fortunately out of our remit.
> Going back to first principals, we want to:
> (1) Not hurt anything (beyond the intentionally designed notification interruptions)
> (2) Notify those potentially impacted
> (3) Collect data
> While I don’t know precisely all the ways folks use PSL, I can imagine the scenario we’re most interested in is software that analyzes a domain name looking thing to determine if it should use DNS to resolve it or do “something else” with it (perhaps like sending it to search or another resolution mechanism). Given that, since all our assumptions and processes are predicated on the potentially colliding strings being queried in the DNS, I think we should pre-advise the PSL as soon as practical and leave it at that. 
>  
> Thx,
> Jeff
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org <mailto:NCAP-Discuss at icann.org>
> https://mm.icann.org/mailman/listinfo/ncap-discuss <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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 --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20231112/e53b77d9/attachment.html>