[dns-operations] [Ext] Re: Browser Public suffixes list

Mon Aug 29 10:55:10 UTC 2022

Hey Jothan,

The OCTO-11 Document is good and important, but is lacking some impotent
items such as Browsers and dependent parties.
* Browsers - E.G. (Chromium, Firefox) whoch have a good process, Safari /
Edge / Samsung which is a patial Enigma or bug reporting process
* Dependent parties - PublicSuffixList, publicsuffix-go, LetsEncrypt

I would say that a lot of good people are trying to help but some of it
have overlapping dependencies and other considerations.

I'm still taking notes and will publish a post when i have all the data
(contact channels, release time frames, addition important relaying
parties, etc...)

*   Thanks,*
*Lavie Ben-Baruch* | *לביא בן-ברוך*
 laviebb at isoc.org.il   |   +972-54-595-7071
Office   |   +972-3-970-0919
 איגוד האינטרנט הישראלי  | Israel Internet Association ISOC-IL
www.isoc.org.il
[image: איגוד האינטרנט הישראלי - ISOC-IL]

On Mon, 29 Aug 2022 at 12:08, Jothan Frakes <jothan at gmail.com> wrote:

> > I am really frustrated that the materials developed for IANA to share to
>> > avoid things like this were not distributed, as awareness would have
>> led to
>> > earlier request, which in turn would have diminished the propagation
>> timing
>> > gap with the browser side.
>>
>> I'll confess to being quite perplexed because it sounds like IANA has
>> dropped the ball, but I am at a loss as to what IANA materials you
>> are referring to. I am not aware of any materials developed for IANA
>> to distribute, and we don't have an existing practice of relaying
>> information about third party projects to TLD managers. Apologies if
>> I've completely overlooked something.
>>
>
> Apologies, Kim, you didn't overlook something.  I didn't mean to infer
> that IANA didn't do something they should have done here, but rather the
> document that was developed would have proactively helped the situation.
> It resulted in OCTO-11 "The Public Suffix List: A Guide for TLD
> Administrators"
> https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf
>
> I scrolled back through my email to May of 2020 when I was collaborating
> with OCTO and completed the materials with them.  Although I was pushing a
> bit for these to be distributed by the IANA to ccTLDs to meet the
> requirements of Recommendation 3 of SAC-070 on ICANN's side, now that I
> scroll through it, I notice I was informed by them at the time that the
> IANA would not be distributing anything as a result of that work.
>
> The exact phrasing from SAC-070, Rec 3 was, "Recommendation 3: To close
> the knowledge gap between registries and popular PSL maintainers, ICANN and
> the Mozilla Foundation should collaboratively create informational material
> that can be given to TLD registry operators about the Mozilla PSL."
>
> I've often seen where advisory committees produce recommendations or
> advice that have to become workstream or other activities, and I get that
> ICANN != IANA or ccTLD obligations necessarily, but it made sense to have
> ccTLDs that light up into the root getting some information to help
> understand some of the unknown unknowns.
>
>
>> I know you and I have had discussions in years past about other TLDs
>> that were missing from the PSL, and I've asked if there were ways IANA
>> could contribute.
>
>
> Yes, I completely appreciate that.  As you know, the PSL has no budget or
> funding and is entirely volunteer maintained, so these conversations are
> typically hallway flyby
>
>
>> The impression I came away with was the PSL guarded
>> its independence and therefore there wasn't a role for IANA.
>
>
> The development community have demonstrated their wants as light-touch,
> sans bureaucratic things, and free-license with no obligations
>
> The requested role for IANA would be to manage and collect subspaces
> directly for ccTLDs in the interactions with ccTLD administrators and then
> publish something that could override those that the PSL was created
> initially to address.  There is no other org with those direct
> relationships that would be more trusted, and the PSL being relied upon in
> performing that role could be sunsetted with something better and more
> appropriate and trusted.
>
>
>> In light of
>> that I'd shared with you some sample code that I felt could immediately
>> be used by the PSL maintainers to identify gaps, or built upon to
>> trigger additions in your workflow:
>>
>>     https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072
>
>
> Thanks for that - it was appreciated, and running it happens when cycles
> available, manually.
>
>
>> If PSL is still not automatically recognizing new TLDs,
>
>
> We have automation tied to the json file that ICANN publishes when nTLD
> contracting occurs, but that json does not include ccTLDs, and the
> automation does not currently parse the tlds.txt from IANA, although there
> is a request from our community of volunteers to update the automation in
> https://github.com/publicsuffix/list/issues/1325
> <https://github.com/publicsuffix/list/issues/1325>
>
> You'll note that I said nTLD contracting entries rather than delegated
> strings in describing the json.  Contracting time on gTLDs was a better
> trigger time for a PSL entry to be added, as it would be in advance of the
> TLD being included in the root.  This helped to bridge the browser
> propagation delays a bit, as a PSL entry would have baked into the
> downstream by the time it lit up.
>
> Problems experienced by the ISOC on this one typically are result from the
> lack of the advance notice for proactive addition on the PSL side, and due
> to the infrequency of new introductions, the rate of occurrence is low -
> and only a problem when a new ccTLD or IDN ccTLD gets added to the root.
>
>
> I would suggest
>> it would still be a better approach to automate rather than putting
>> the burden on each and every TLD manager to manually request to be
>> added. After all, the underlying truth of a TLD's existence is easily
>> ascertainable with existing tools without adding extraneous workflow
>> steps.
>>
>
> Not disagreeing at all on the automation perhaps being beneficial, as
> we're running long on requests because the volunteer cycles are our only
> fuel so it lets us do more, faster and accurately.   Utopia would be that
> entries are always being directed by the ccTLD administrator, so that it is
> representative of their intentional behaviour for their TLD being expressed.
>
> I'll also note that automation would have not been a solution for ISOC's
> issue due to the presence of the stub zones, despite any of the existing
> tools, no automation nor existing tools could have divined the four stub
> zones from the minds of the administrators.
>
>  I still think that sharing a link to OCTO-11 "The Public Suffix List: A
> Guide for TLD Administrators" or at least a mention of the PSL would be
> beneficial to consider distributing to whatever new ccTLDs or IDN ccTLDs
> get added to the root.
>
> -Jothan
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220829/cd5ed65a/attachment.html>